_REENT_SMALL IO broken

[Jeff Johnston]

Attached is the patch I have been testing.  It seems to do the trick. 
If you want to test it out a bit further, let me know, otherwise, I'll 
commit it.

BTW: you were right about the feof, clearerr, and ferror macros.  I 
changed stdio.h to force them to be functions.

-- Jeff J.

Jeff Johnston wrote:
> 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.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: small_reent.patch
Type: text/x-patch
Size: 22289 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20060926/3a2859c1/attachment.bin>