sys_errlist

[J. J. Farrell]

> From: Mumit Khan <khan@thor.xraylith.wisc.edu>
> 
> John Fralinger <fralinjh@ei.dupont.com> writes:
> > 
> > I am still confused about when to use an "_" and when not to.
> 
> sys_nerr, sys_errlist are not mandated by various standards, and the
> runtimes tend to expose these non-standard items with a leading
> underscore. This unfortunately causes trouble with lots of the existing 
> Unix code, and that's unfortunate. Perhaps Cygnus will consider exposing
> the non-underscored version as well via the export definition file?

These never made it into any International or vendor-independent
standard because they are difficult to implement when using message
catalogues. However, the versions without the leading underscore
are a Level 1 requirement in the third edition and earlier of the
System V Interface Definition, so any UNIX-like implementation
calling itself compatible with System V Release 4 (SVR4) or earlier
must export these without the underscore. The SVID also says that
the correct way to access these interfaces is to declare them as
externs in your code, not to expect them to be declared in a header.

Other C runtime implementors thought the functionality useful, but
couldn't export the names as originally defined since they pollute
the user's name-space - hence the versions with the leading
underscore which are in the library implementor's name-space.

Since the non-underscore versions are required to be present in
the interface definition which many modern UNIXes are based on,
I'd say that cygwin should expose them, but no-cygwin shouldn't.
Is it possible to expose them in a way which makes user declaration
work, as mandated by the SVID, rather than requiring the <errno.h>
inclusion? Both should expose the underscore versions since there's
no harm doing so.

Nothing written in the last 10 years or so should be using these
anyway; strerror() was introduced in C89 and POSIX.1 to replace them,
as Mumit pointed out.


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com