newlib: fputs aborts on ARM

Richard Earnshaw
Wed Nov 16 21:31:00 GMT 2005

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:
> 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].


[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.

More information about the Newlib mailing list