_REENT_SMALL IO broken

[Jeff Johnston]

Paul Brook wrote:
>>_REENT_SMALL was specifically added for embedded platforms that are
>>extremely tight on storage (some verging on crippled IMO).  It should
>>not be used by platforms that just want to save a few bytes.  It is not
>>surprising that these platforms can't do everything in a Standard's test
>>bucket (some of them don't even do file I/O).  Storing away the standard
>>streams isn't something any reasonable program other than a concocted
>>standard-test is going to do.  It certainly won't be found in real code
>>written for such platforms.
> 
> 
> My interest here is for armv7. This covers everything from tiny 
> microcontrollers with only 2k ram to large SoC systems many megabytes of 
> memory. It'd be nice to be able to use the same library for both.
> 
> Comparing a file pointer to stdin does occur in real code. For example gdb 
> contains several instances of "if (instream == stdin)".
> 

Granted, but gdb is not going to run on a _REENT_SMALL platform and such 
a problem is solved by adding a first reference (e.g. fflush(stdin)). 
_REENT_SMALL platform code makes concessions as needed.  I think the 
answer in this situation is to add another macro to control whether the 
FILE structs are found in the small reent struct or not (default no). 
This will solve your problem and won't interfere with existing 
_REENT_SMALL builds.

> 
>>>There are also more subtle bugs that can occur when using the dummy FILE*
>>>with the feof, ferror, and clearerr macros.
>>
>>These macros should be ok.  You shouldn't be at EOF since you haven't
>>issued any read and you haven't caused any error to occur prior to the
>>first reference.
> 
> 
> The user could still be using the old value via a cached pointer, as in my 
> previous example or more commonly by stdout being passed as a function 
> argument. This is definitely fairly common practice. eg:
> 
> void frob(FILE *f)
> {
>  while (!feof(f))
>   fgetc(f);
> }
> int main()
> {
>  frob(stdin);
>  return 0;
> }
> 
> It's arguable whether it's ok to change the value of stdin, but if it does 
> change then the old pointer must continue to function correctly.
>

Yes, you are right.  I have incorporated this feature into my patch 
which I am currently testing.

-- Jeff J.