The reentrancy structure?
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
85% of all the calls in POSIX 1003.1b and the Open Group Single UNIX
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
on whether the next number in the sequence is 20 or 3. Jeff is 0-2
ISO C, history or a mix at this point? I know it was that way back in
dark ages of System 7 when an 8086 looked like a multi-user computer. :)
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