Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Date: Mon, 3 Jul 2000 15:36:35 +0200 (MEST)
Message-Id: <200007031336.PAA23582@mail.bln1.siemens.de>
To: cygwin AT sourceware DOT cygnus DOT com
From: towo AT computer DOT org
Subject: RE: include incompatibilities

I had written:
: I had lamented about incompatible changes in include files.
: May I repeat the practical essence of my previous mail which is the 
: question: How can these things be detected by #ifdef's without 
: referring to actual system specifics as below?
: 
: #include <errno.h>
: #ifdef __CYGWIN__	/* and version > something ... ! */
: #define sys_nerr _sys_nerr
: #define sys_errlist _sys_errlist
: #endif
: 
: (On "classical" systems, the exported names are without underlines - 
: why do these name manglings have to be imposed on us?)

Thanks to various people who pointed out that this has not been standard 
for years (although that doesn't answer the question why it had to be 
changed suddenly in cygwin - anyway); 
I had apparently been mislead by the Linux manpage:
> NAME
>        perror - print a system error message
> SYNOPSIS
>        ...
>        const char *sys_errlist[];
>        int sys_nerr;
> CONFORMING TO
>        ANSI C, BSD 4.3, POSIX, X/OPEN
So apparently this manpage is wrong with respect to the "conforming" 
attributes of these two definitions.

Also, there are some reasons I did not use strerror().
One is, strerror may depend on setlocale but setlocale is not available 
on older systems. Another is incompatibilities with respect to undefined 
values:
Linux:
> SYNOPSIS
>        char *strerror(int errnum);
> RETURN VALUE
>        The  strerror()  function returns ... an unknown error message 
>        if the error code is unknown.

Sun:
> SYNOPSIS
>      char *strerror(int errnum);
> ERRORS
>      strerror returns NULL if errnum is out-of-range.

So there is no real standard here either...


Chris Faylor also said:
: You're talking about normal problems with porting software between various
: systems.  This kind of thing is a fact of life that you have to live with.
Certainly. But we should hope that everyone is striving to keep these 
unproductive efforts to a minimum nowadays.

: It's the reason for things like autoconf and MetaConfig.  Perhaps using
: one of those two packages is the solution you're straining for.
If only these were easy to handle - I gave up an attempt to use autoconf 
for my software after I realized that just getting the basics would 
require me several hours of study - or is there any HOWTO or rather 
mini-HOWTO available for autoconf?

Thomas Wolff

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com