The reentrancy structure?

Joel Sherrill joel.sherrill@OARcorp.com
Sun Jul 14 09:27:00 GMT 2002



"H. Peter Anvin" wrote:
> 
> J. Johnston wrote:
> >
> > Alright, now that I know what you want to do, there are a couple of things you
> > haven't thought of.
> >
> > First of all, the library routines dealing with default std streams, use
> > the _r macros - e.g. a getchar() call won't link in your code.
> >
> 
> I have noticed that -- I wanted to modify them.
> 
> > Secondly, you have to deal with the std stream initialization routines in
> > libc/stdio/findfp.c.  These routines get triggered by the CHECK_INIT macro
> > which looks at the __sdidinit flag in the reent struct.
> >
> > What you could do is to create a sys directory for your platform and add
> > a sys/stdio.h header file.  In it, create a reference to an external integer
> > (e.g. extern int __io_initialized; ).
> >
> > Add your own versions of the std stream macros that are identical to the ones
> > in stdio.h, only they also set __io_initialized to a value.
> >
> > #define stdin  (__io_initialized = 1, _REENT->_stdin)
> > #define _stdin_r(x)     (__io_initialized = 1, (x)->_stdin)
> 
> Interesting idea.
> 
> > Now, the only thing you have to do is skip the current definitions in stdio.h.
> > Just protect them with a #ifndef __STD_STREAMS_DEFINED__ which you set in
> > your sys/stdio.h.
> >
> > The __io_initialized integer is defined in your special code.  You will also want
> > to catch a user who might access the std file descriptors
> > directly (e.g. write (2, "hello world\n", 12); ).  If you can dup2() the
> > file descriptors, then you are set.  Otherwise, you should use freopen() so that
> > the __sdidinit flag is set and then you will have to intercept any base OS calls
> > that use the std fds so that they translate to the fds opened at initialization.
> 
> I'm not concerned about Unix-style file descriptors 0, 1, 2... -- I'm
> using a non-Unix scheme for allocating file descriptors.  Since this
> platform won't have processes, Unix software won't be able to port anyway.

Not to be picky here but not having processes does not place a hard 100% 
limit on porting UNIX software.  RTEMS has no processes either but has
about
85% of all the calls in POSIX 1003.1b and the Open Group Single UNIX
Specification.
Porting UNIX software to RTEMS can be quite trivial.

And other than 0,1,2 I don't think you will find a lot of software
depending
on whether the next number in the sequence is 20 or 3.  Jeff is 0-2
POSIX,
ISO C, history or a mix at this point?  I know it was that way back in
the
dark ages of System 7 when an 8086 looked like a multi-user computer. :)

>         -hpa

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985



More information about the Newlib mailing list