[RTEMS Project] #3870: libc_reent set up is broken

[RTEMS trac]

#3870: libc_reent set up is broken
-------------------------+---------------------
 Reporter:  Chris Johns  |       Owner:  (none)
     Type:  defect       |      Status:  new
 Priority:  high         |   Milestone:  5.1
Component:  score        |     Version:  5
 Severity:  normal       |  Resolution:
 Keywords:               |  Blocked By:
 Blocking:  3859         |
-------------------------+---------------------

Comment (by Sebastian Huber):

 Replying to [comment:4 Chris Johns]:
 > Replying to [comment:3 Sebastian Huber]:
 > > Replying to [comment:1 Chris Johns]:
 > > Sorry, I don't know the problem you want to solve.
 >
 > Telnet is broken with `joel` script. This is compounded by the shell's
 main loop handling of `stdout` and `stdin` also being broken. See #3859.
 You see it when you create a new thread in the telnet shell thread, ie a
 `joel` command, and you want the IO to inherit the parent's `stdin` and
 `stdout`.
 >
 > Create a thread and do not access any libc calls then do ...
 > {{{
 >   stdin = fopen("a-file", "r");
 >   stdout = my_stdout;
 >   setvbuf(stdout, NULL, _IONBF, 0);
 >   printf("hello will appear on the global stdout\n");
 > }}}
 > The `stdin` and `stdout` files pointers well be initialised to the
 globals. If you make a libc call before this type of logic, for example
 `fflush(stdout);` things work.
 It would be good to have a test case that shows the problem. Maybe for
 libtests/newlib01. The Newlib re-entrant and in particular the standard
 file pointer handling is quite subtle and brittle. In the past it was
 helpful to me to work with test cases and use a debugger to figure out
 what is going on. To me it looks that you need reference counted FILE
 objects?

--
Ticket URL: <http://devel.rtems.org/ticket/3870#comment:6>
RTEMS Project <http://www.rtems.org/>
RTEMS Project