C runtime library for Unix

[Paul Edwards]

I would like to port PDPCLIB:

http://sourceforge.net/projects/pdos/

my public domain C runtime library for DOS, OS/2,
Win32, MVS to Unix now.

I am a bit perplexed as to how to do this. Unix/Posix
systems provide open() with which I can implement
fopen(). But then Posix is also required to define fopen(),
so this is not the level at which I need to implement it.

Although I don't think the CRT should be polluting the
namespace by using open() in the first place.

If the lower level is platform-dependent, then the platform
I wish to target is Linux.

Can someone get me started?

Thanks. Paul.

[Keith Thompson]

"Paul Edwards" <ke******@nospp aam.w3.towrites :

"Keith Thompson" <ks***@mib.orgw rote in message
news:ln******** ****@nuthaus.mi b.org...

>I just tried a small test program that defines an external function
called "open". It worked with no problem. The systems I tried it on
also have a system function called "open";

Your test is inadequate because you wouldn't see the
problem unless you did an fopen() and suddenly your
code got executed by the C library.

Ok, I just tried that, and it worked fine, to my complete lack of
surprise. fopen() opened the file correctly, and strace shows calls
to the system's open() function; the program also called my own open()
function.

You didn't really expect a major implementation to get this wrong, did
you?

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[santosh]

Paul Edwards wrote:

"Tor Rustad" <to********@hot mail.comwrote in message

<snip>

On Linux you go from user space to kernel space via interrupt
0x80, using inline assembler... ref. <asm/unistd.hand
_syscallN() macros... right?

Well I didn't know that until you told me just now.

Any other way will cause your CRT to be dependant on another library in
the system, not the way I think that you want it.

On Win32 you load kernel32.dll and call the functions via
functions pointers... right?

Well, not the way I'm doing it. I'm using the published
interface, which means I have coded CreateFile() in my
implementation of fopen(), which means I am polluting
the namespace.

By 'coded' you do mean calling CreateFile() defined in kernel32.dll,
don't you. If so that won't pollute the namespace more than other C
libraries will do.

So exactly how do the linker see any function names which
is invading the user name space?

What am I missing???

You're missing the fact that I thought it was a good idea to
use the OS's published interface, at least for Win32 and
OS/2.

That's how it ought to be done. You're not polluting the namespace, the
OS is, and that's a restriction we've got to live with.

And
now I am looking into Unix and wondering what I should
use as the "official interface".

The system call interface exported by the kernel. For the case of Linux
under x86, it's through INT 0x80. Consult the kernel's source and
documentation for details.