Rudi Schlatte <rudi@...> writes:
> Christophe Rhodes <csr21@...> writes:
>> Isn't there another issue involved with specifically SB-POSIX?
>> Remember, we're encouraging people _not_ to :USE the package, so in
>> that sense exporting SYSCALL-ERROR isn't the whole story, I think.
>> Something in me wants a package called SB-POSIX-INTERFACE or somesuch,
>> which can be USEd, into which SYSCALL-ERROR would go and be exported
>> from; SB-POSIX would be strictly for constants and functions
>> associated with manual pages. Does that make sense?
> I wouldn't want to :use sb-posix; I'd like exported symbols purely
> from a source-code-is-documentation point of view. Seeing double
> colons in code makes me feel uneasy, that's all.
> What other symbols beside syscall-error would sb-posix-interface
> export? If it's only the one symbol, I'm not sure it's worth the
> effort. (But I don't have strong feelings one way or the other, so
> that's not a vote for one way or the other.)
Since the advent of threads on most Unices the C library is tending
more and more towards stateless library functions. Errno is one of
the few stateful parts of the C library other than stuff like strtok()
which gets kept around for hysterical raisins.
You might also want to put a couple of things in that define the POSIX
version. There are three CPP macros that are relevant, though how
you'd get them defined without groveling through the headers
(specifically, unistd.h) is beyond me. The POSIX versions supported
by the system are supposed to be in _POSIX_VERSION, _POSIX2_VERSION,
and if the implementation supports XSI then also _XOPEN_VERSION.
There are a bunch of other constants in that header that give
information regarding various parts of POSIX support. These are all
defined to contain either -1, 0, or the value 200112L (the POSIX
version date as a C long int). These probably should not be generated
at compile time since the binary thus obtained could be moved to some
other system of the same architecture where the C library was
different. Getting them at runtime of course requires groveling over
the <unistd.h> header file. They could be neatly wrapped up into a
Lisp structure rather than polluting the namespace with tons of
specvars. Their values in Lisp should probably be NIL (-1 or 0) or
the version number.
Here's the list taken from IEEE Std 1003.1, 2003 edition. It's
available at no cost at http://www.unix.org, but you have to register for
their demographic purposes. I skipped a few, explanation is below.
Note that I skipped the _V6 and _XBS5 constants which give details on
the size of ints, longs, etc.
In unistd.h there are also a bunch of other constants for use with
various functions. These shouldn't be global. Their globality in C
is an artifact of the language.
James A. Crippen <james at unlambda.com> Lambda Unlimited
61.2204N, -149.8964W Recursion 'R' Us
Anchorage, Alaska, USA, Earth Y = \f.(\x.f(xx))(\x.f(xx))