Re: newlib: fputs aborts on ARM

[Jeff Johnston <jjohnstn at redhat dot com>]

Richard Earnshaw wrote:
> 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].

Tom,

Just to add to Richard's comment:  if you look at the standards, you 
will see that the I/O functions (fputc, fputs, ...) do not define an 
error situation for when the FILE pointer is invalid.  The following 
test run with glibc on i686 Linux fails with a SIGSEGV when an attempt 
is made to access the FILE pointer and lock the file.

#include <stdio.h>
#include <errno.h>

int main()
{
  int ret;
  FILE *fp = NULL;

  errno = 0;

  ret = fputc ('a', fp);

  return 0;
}

-- Jeff J.