On Wed, 2005-11-16 at 08:10, Tom Walsh wrote:
Well, I've run into a problem on this project. Just to recap, I've
compiled NewLib-1.13.0 with the following options:
CFLAGS_FOR_TARGET = -O2 $(CFLAGS) -DREENTRANT_SYSCALLS_PROVIDED
-DINTEGER_ONLY -DPREFER_SIZE_OVER_SPEED
I've done this to enable the various reent stubs. The various stubs are
defined in my application to interact with a FAT16 filesystem driver to
an MMC card. So far all the file stream functions are working: fopen(),
fread(), etc.. What is a problem is that if a call to fputs() is made
with an invalid file handle (NULL), then fvwrite() ultimately calls the
malloc / free functions. While there, data is allocated, then when the
assigment of the buffer space is made to the file handle, the ARM
processor triggers a Data Abort Exception (write to non-writeable space).
At least that is how I followed the newlib code via the JTAG debugger.
Normally, an invalid file handle would cause fputs() to return -1 (EOF)
for operational error? While in a perfect world, we would all write:
I've never come across any real system that would let you get away with
passing an invalid file descriptor the the various file operations. It
simply won't work. Consider the macro implementation of getc which
directly manipulates the FILE structure inline.
Normally you can just get away with testing that the file opened
correctly and taking corrective action in that case. The pedantic will
check every file write/read and that is certainly good practice because,
for example, continuting to hammer a full file system can cause all
sorts of weirdness to happen[1].
R.
[1] I've seen a full OS brought to its knees by continuously trying to
print on the console that some file system is full. This was caused by a
program trying to generate an enormous log file with no error checking
on the writes.