_REENT_SMALL IO broken
Jeff Johnston
jjohnstn@redhat.com
Mon Sep 25 22:43:00 GMT 2006
Paul Brook wrote:
> On _REENT_SMALL targets stdin/out/err are initialized to dummy values. The
> read FILE structures are then allocated the first time the IO functions are
> used.
>
> However this doesn't work because the IO routines don't do any translation
> between the initial dummy structures and the real FILE structures. This means
> the first call to an IO routine fails.
>
> If fact if the user creates a local copy of stdout before writing to it, then
> uses that all IO will fail.
>
> I see a few possibilities for fixing this:
>
> a) Every use of a file descriptor needs to check if it has the read FD, or a
> dummy copy. In this case there's no point having the dummy structure, we can
> just assign stdin/out/err magic values. As a bonus _reent gets even smaller,
> at the expense of a small code size increase.
> b) Split __FILE into static (__sFILE_fake) and dynamic (the rest) sections.
> This introduces an extra level of indirection for acessing the dynamic
> fields.
> c) Decide it's not worth the effort and allocate the full FILE structure in
> _reent.
>
> (c) is the easiest to implement. (b) should be fairly straightforward because
> any missed bits will cause build failures. (c) is the most work because it
> requires manually auditing the IO code.
>
> Any preference, or suggestions of better solutions?
>
IMO, the right solution is a) but not the 2nd part of your proposal.
The reason we have the dummy structure is to handle the stdio macros
(e.g. getc and putc). For speed/compactness, we want them to think they
are operating on a real FILE * and we set the values such that we always
force a function call to occur based on their regular logic path.
Now, if there were a CHECK_INIT() that also took an fp argument, then it
could have an optional _REENT_SMALL path that could check if the fp is
currently set to the fake fp then reset it properly. This is relatively
easy, yet tedious, but should do the trick.
Let me know what you think.
-- Jeff J.
> Paul
More information about the Newlib
mailing list