Re: C runtime library for Unix

Paul Edwards wrote:

"Eric Sosman" <Eric.Sosman@xxxxxxx> wrote in message news:1163805399.935710@xxxxxxxxxxx

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
esosman@xxxxxxxxxxxxxxxxxxx
.

Relevant Pages

  • C++ Managed Wrapper DLL exposes unmanaged names too - help
    ... classes using specific namespace but same class names as unmanaged. ... from the wrapping dll, thus hiding names of the wrapping namespace. ... one can only be accessed via "managedWrapper.sampleClass" from client ... What is the hint to overcome that - renaming all the wrapper of 7000 classes ...
    (microsoft.public.dotnet.framework.interop)
  • Re: Mug bought from overseas
    ... > Just bought a coffee mug from overseas that I couldn't get from the UK. ... > inside this wrapper. ... Seller had two of these items at ... You bought and paid for a mug, you received a broken one, it's down to the ...
    (uk.people.consumers.ebay)
  • Re: [PATCH] private mounts
    ... >>I suppose it will be called by the login process or by wrappers like ... shell were actually modified to implement setnamespace, ... The wrapper I mentioned will usurally not be needed for normal operation, ... The mount would be a part of the current namespace, ...
    (Linux-Kernel)
  • problem with calling C++/CLI wrapper to C++ code from C# applicati
    ... only to the wrapper and the wrapper has a reference to unmanaged dll. ... reference only to the wrapper namespace. ... _CppLib = new CCppLib; ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Override existing class name with custom assembly?
    ... > They suggest sandboxing which wraps the OLE DB access code, give the wrapper ... > full trust so OLE DB works, but the wrapper doesn't require callers to have ... I was thinking about "sandboxing" the whole OleDb Namespace. ...
    (microsoft.public.dotnet.general)