newlib: fputs aborts on ARM

[Tom Walsh]

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:

============== begin ==================
if (filehandle) result = fputs ("dadah", filehandle);
if ((filehandle) == NULL || (result == EOF)) WeFailedSomehow ();
=============== end ==================


or whatever, that is very tedious and counter intuitive of many years of 
simply checking fopen() for failure and taking action at that point.   
Then allowing dead write operations to gracefully fail:

============== begin ==================
if ((result = fputs ("dadah", filehandle)) == EOF) WeFailedSomehow ();
=============== end ==================

That is the problem, I can correct for a NULL filehandle within 
fvwrite(), assuming this is a central routine to: fputc(), fprintf(), 
fwrite(), etc..  However, how should I proceed with making corrections 
as I am not intimately familiar with how errno should / should not be 
set / could be set when encountering such an errorneous situation.

I'm not afraid of doing the work, just that I don't want to come up with 
_my_ solution only to have it be _nonstandard_.

Regards,

TomW





-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------