At 10:42 AM 6/7/2002 -0400, Josh Wilmes wrote:
> > PIO_push_payer(...., &pio_sys_layer, ... )
> >
> > This means renaming all of io_unix/io_win32 to io_sys
> > since you would never have 2 OS dependant layers compiled at the
> > same time. I've just been too lazy to rework it.
>
>So something like the way platform.[ch] work then? copy
>io_{unix|win32|stdio} to io_sys.c during the build process?
Yeh, thats what I was thinking.
>If we're serious about this miniparrot stuff, i'd like to see the code
>reorganized so that all the platform-specific stuff lives in one place,
>and everything else has to be pure ANSI C.
I think thats a good idea even if we didn't have miniparrot. The
exposed interface in io.c is platform independant.
>Found 1911 symbols defined within the 48 supplied object files.
>Found 57 external symbols
>Of these, 8 are not defined by ANSI C89:
> close (in io/io_unix.o)
> creat (in io/io_unix.o)
> isatty (in io/io_unix.o)
> lseek (in io/io_unix.o)
> open (in embed.o,io/io_unix.o)
> read (in core_ops.o,core_ops_prederef.o,embed.o,io/io_unix.o)
> stat (in embed.o)
> write (in core_ops.o,core_ops_prederef.o,io/io_unix.o)
>
>
>Ideally, for miniparrot, there should be nothing spit out here. All told,
>this isn't too bad. Most are in the IO layer and embedding.
A few other issues I've seen:
The direct stat and mmap calls should be moved out of embed.c
Also, I think interpreter.c has platform specific oplib loading code,
and assumes unix .so paths.
-Melvin
