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.

[Eric Sosman]

Paul Edwards wrote:

"Eric Sosman" <Er*********@su n.comwrote in message news:1163805399 .935710@news1nw k...

>>>The __syscall_open( ) is presumably what the OS exports,
and what I need to use to avoid polluting the user's namespace
by a direct call to open().

I haven't found where __syscall_open( ) is defined yet,
but I found a sys_open() in syscalls.h. Maybe that's the
proper one to use.

Why is it better to pollute the user's namespace
with sys_open() than with open()?

Technically it isn't, but since no-one actually uses sys_open(),
I didn't think anyone would notice.

They might be *more* likely to notice than if you'd just
used open(). Programs written with portability in mind are
quite likely to avoid making native O/S calls directly, but
to route them through "wrapper" functions instead. On many
systems the wrappers will simply call the native interface
without further ado, but they provide a convenient place to
insert special handling for a system that requires it or can
take advantage of it. For example, a wrapper for open() might
just take its three arguments and call open() on most systems,
but on Frobozz Unix there's extra code to set a special mode
bits when opening anything under the "/var" directory -- for
some sort of esoteric FUX-specific reason you and I don't
understand.

Now: The wrapper can't be called open(), obviously. As
a developer of this portable program, what name are you likely
to choose? Actual examples I've seen include OSopen() and
OsOpen(), but it wouldn't surprise me in the least to find that
someone had decided to form wrapper names by prefixing sys_ to
everything ...

I have the same problem with Win32. It is polluting the user's
namespace with CreateFile(). I don't know how to get around
that. I wonder what other C compilers do?

Special games with linkers, if they bother at all. There'll
be some sort of magic that allows the user to write and use an
open() function while library denizens like fopen() can still
somehow call the system's open(). There'll be "weak symbols"
and possibly a lot of renaming going on -- or, sometimes, they'll
just say "Tough: You bought our system, you bought our names."
It's a jungle out there.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Keith Thompson]

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

"Tor Rustad" <to********@hot mail.comwrote in message
news:11******** *************@m 73g2000cwd.goog legroups.com...

>Eric Sosman skrev:

Paul Edwards wrote On 11/17/06 15:20,:

[...]

The __syscall_open( ) is presumably what the OS exports,
and what I need to use to avoid polluting the user's namespace
by a direct call to open().

Why is it better to pollute the user's namespace
with sys_open() than with open()?

I don't get it. Why does the standard library pollute user's
namespace?

Internally, the library will have e.g. <open.c>, which calls the
OS functions. So those OS calls shouldn't be visable to the
library caller... so is it a link problem we talk about here?

Yes, the problem will occur at link time. The C library is
not meant to be dependent on functions which are in the
user's namespace. The C library is allowed to use names
such as __open() or _Open() (on a case-sensitive system),
but not open().

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"; you have to include a
non-standard header to make it visible. There was problem linking the
program. I don't know (or much care) how the system does this; it
just works.

--
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.

[Spiros Bousbouras]

Keith Thompson wrote:

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

"Tor Rustad" <to********@hot mail.comwrote in message
news:11******** *************@m 73g2000cwd.goog legroups.com...

Eric Sosman skrev:
Paul Edwards wrote On 11/17/06 15:20,:

[...]

The __syscall_open( ) is presumably what the OS exports,
and what I need to use to avoid polluting the user's namespace
by a direct call to open().

Why is it better to pollute the user's namespace
with sys_open() than with open()?

I don't get it. Why does the standard library pollute user's
namespace?

Internally, the library will have e.g. <open.c>, which calls the
OS functions. So those OS calls shouldn't be visable to the
library caller... so is it a link problem we talk about here?

Yes, the problem will occur at link time. The C library is
not meant to be dependent on functions which are in the
user's namespace. The C library is allowed to use names
such as __open() or _Open() (on a case-sensitive system),
but not open().

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"; you have to include a
non-standard header to make it visible. There was problem linking the
program. I don't know (or much care) how the system does this; it
just works.

Do you mean there was NO problem linking ?

[Keith Thompson]

"Spiros Bousbouras" <sp****@gmail.c omwrites:

Keith Thompson wrote:

[...]

>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"; you have to include a
non-standard header to make it visible. There was problem linking the
program. I don't know (or much care) how the system does this; it
just works.

Do you mean there was NO problem linking ?

Yes.

% cat foo.h
#ifndef FOO_H
#define FOO_H
void open(void);
#endif

% cat foo.c
#include <stdio.h>
#include "foo.h"
void open(void)
{
printf("In open()\n");
}

% cat main.c
#include "foo.h"

int main(void)
{
open();
return 0;
}
% gcc foo.c main.c -o main
% ./main
In open()

--
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.

[CBFalconer]

Keith Thompson wrote:

>

.... snip ...

>
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"; you have to include a
non-standard header to make it visible. There was problem linking
the program. I don't know (or much care) how the system does this;
it just works.

This will normally be because the run time library is searched
last, and only for items that are so far undefined. This is not
mandated by the standard, but is in practice the methodology. The
success is also affected by how finely the library is sub-divided,
for example the code block for malloc will usually include both
free and realloc, so they can only be replaced as a complete triad.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>

[Keith Thompson]

CBFalconer <cb********@yah oo.comwrites:

Keith Thompson wrote:

>>

... snip ...

>>
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"; you have to include a
non-standard header to make it visible. There was problem linking
the program. I don't know (or much care) how the system does this;
it just works.

This will normally be because the run time library is searched
last, and only for items that are so far undefined. This is not
mandated by the standard, but is in practice the methodology. The
success is also affected by how finely the library is sub-divided,
for example the code block for malloc will usually include both
free and realloc, so they can only be replaced as a complete triad.

And the result of this is that a C program can use any identifier it
likes as long as it's not reserved by the standard, even if it's one
like "open" (or "sys_open", or whatever) that might be used by the
operating system.

--
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.

[Tor Rustad]

Paul Edwards skrev:

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

Eric Sosman skrev:

>
Why is it better to pollute the user's namespace
with sys_open() than with open()?

I don't get it. Why does the standard library pollute user's
namespace?

Internally, the library will have e.g. <open.c>, which calls the
OS functions. So those OS calls shouldn't be visable to the
library caller... so is it a link problem we talk about here?

Yes, the problem will occur at link time. The C library is
not meant to be dependent on functions which are in the
user's namespace. The C library is allowed to use names
such as __open() or _Open() (on a case-sensitive system),
but not open().

I still don't get it...

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

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

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

What am I missing???

--
Tor

[Paul Edwards]

"Tor Rustad" <to********@hot mail.comwrote in message news:11******** **************@ e3g2000cwe.goog legroups.com...

Paul Edwards skrev:

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

Eric Sosman skrev:

Why is it better to pollute the user's namespace
with sys_open() than with open()?
>
I don't get it. Why does the standard library pollute user's
namespace?
>
Internally, the library will have e.g. <open.c>, which calls the
OS functions. So those OS calls shouldn't be visable to the
library caller... so is it a link problem we talk about here?

Yes, the problem will occur at link time. The C library is
not meant to be dependent on functions which are in the
user's namespace. The C library is allowed to use names
such as __open() or _Open() (on a case-sensitive system),
but not open().

I still don't get it...

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.

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.

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. I didn't have this problem in DOS because the only
interface they provided was assembler interrupts. And
now I am looking into Unix and wondering what I should
use as the "official interface".

BFN. Paul.

[Paul Edwards]

"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.

BFN. Paul.

[Tor Rustad]

Paul Edwards skrev:

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

Eric Sosman skrev:
>
Why is it better to pollute the user's namespace
with sys_open() than with open()?

[...]

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.

No problem.

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.

With the C compilers I have used at least, unless using
function pointers... a dynamicly linked Win32 function
was prefixed with:

__declspec(dlli mport)

which translate e.g. CreateFile(...) into

__imp__CreateFi le(...)

i.e. no polluting of user's name space at link time. I have
never used gcc on Win32... so if this is really a problem
in that environment, you can solve it by using another
C compiler.

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. I didn't have this problem in DOS because the only
interface they provided was assembler interrupts.

Methinks, I'm not the one missing something here... ;-)

--
Tor