C++ interface build on FreeBSD 4.2 broken?

Tatsuo Ishii <t-ishii@sra.co.jp> writes:

It is reported that building C++ interface on FreeBSD 4.2 fails.
Can someone comment on this?

In file included from ../../../src/include/postgres.h:40,
from pgconnection.h:41,
from pgconnection.cc:18:
../../../src/include/c.h:997: conflicting types for `int sys_nerr'
/usr/include/stdio.h:224: previous declaration as `const int sys_nerr'
gmake[3]: *** [pgconnection.o] Error 1

A quick look at hub.org confirms:

uname -a

FreeBSD hub.org 4.2-STABLE FreeBSD 4.2-STABLE #0: Tue Dec 19 07:52:31 EST 2000 root@hub.org:/home/projects/pgsql/operating_system/obj/home/projects/pgsql/operating_system/src/sys/kernel i386

grep sys_nerr /usr/include/*.h

/usr/include/stdio.h:extern __const int sys_nerr; /* perror(3) external variables */

Sigh. Looks like we need yet another configure test. Or maybe it's
better to just cut and run on the check for in-range errno; although
I put that in to begin with, I'm certainly starting to wonder if it's
worth the trouble. Comments anyone?

regards, tom lane

Tatsuo Ishii writes:

c++ -pipe -O3 -mpentiumpro -Wall -fpic -DPIC -I/usr/local/ssl/include
-I../../../src/include -I../../../src/interfaces/libpq -c -o pgconnec
tion.o pgconnection.cc
In file included from ../../../src/include/postgres.h:40,
from pgconnection.h:41,
from pgconnection.cc:18:
../../../src/include/c.h:997: conflicting types for `int sys_nerr'
/usr/include/stdio.h:224: previous declaration as `const int sys_nerr'
gmake[3]: *** [pgconnection.o] Error 1

C++ apparently doesn't allow this, but C does. So you have to put #ifndef
__cplusplus at the appropriate place in c.h.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Peter Eisentraut <peter_e@gmx.net> writes:

../../../src/include/c.h:997: conflicting types for `int sys_nerr'
/usr/include/stdio.h:224: previous declaration as `const int sys_nerr'

C++ apparently doesn't allow this, but C does. So you have to put #ifndef
__cplusplus at the appropriate place in c.h.

Er, what will you ifdef exactly, and what are the odds that it will fail
on some other platform? (On my machine, for example, sys_nerr is
definitely NOT declared const by the system header files, and so adding
a const decoration to our declaration would fail.)

I think our choices are to do a configure test or to stop using sys_nerr
altogether. At the moment I'm kind of leaning towards the latter.
I suspect machines whose strerror() is without a rangecheck are history,
and even if they're not, it's unproven that we ever pass a bogus errno
to strerror anyway.

regards, tom lane

Tom Lane writes:

Peter Eisentraut <peter_e@gmx.net> writes:

../../../src/include/c.h:997: conflicting types for `int sys_nerr'
/usr/include/stdio.h:224: previous declaration as `const int sys_nerr'

C++ apparently doesn't allow this, but C does. So you have to put #ifndef
__cplusplus at the appropriate place in c.h.

Er, what will you ifdef exactly,

+ #ifdef __cplusplus
#ifdef HAVE_SYS_NERR
extern int sys_nerr;
#endif
+ #endif

and what are the odds that it will fail on some other platform?

I don't see how it would fail. At least it won't add more possible
failure cases.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Peter Eisentraut <peter_e@gmx.net> writes:

Tom Lane writes:

Er, what will you ifdef exactly,

+ #ifdef __cplusplus
#ifdef HAVE_SYS_NERR
extern int sys_nerr;
#endif
+ #endif

and what are the odds that it will fail on some other platform?

I don't see how it would fail. At least it won't add more possible
failure cases.

If that can't fail, why do we need to provide a declaration of sys_nerr
at all?

regards, tom lane

Tom Lane writes:

Peter Eisentraut <peter_e@gmx.net> writes:

Tom Lane writes:

Er, what will you ifdef exactly,

+ #ifdef __cplusplus

#ifndef, I meant. I.e., only declare it when in C, since libpq++ does not
use it. libpq doesn't use it either, but it uses tons of strerror().

#ifdef HAVE_SYS_NERR
extern int sys_nerr;
#endif
+ #endif

and what are the odds that it will fail on some other platform?

I don't see how it would fail. At least it won't add more possible
failure cases.

If that can't fail, why do we need to provide a declaration of sys_nerr
at all?

regards, tom lane

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Peter Eisentraut <peter_e@gmx.net> writes:

libpq doesn't use it either, but it uses tons of strerror().

And also there are quite a few places in the backend that use strerror()
directly. This lack of consistency seems like another reason to forget
about testing errno against sys_nerr in elog() ...

regards, tom lane

On Sat, Jan 20, 2001 at 02:18:55PM -0500, Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

libpq doesn't use it either, but it uses tons of strerror().

And also there are quite a few places in the backend that use strerror()
directly. This lack of consistency seems like another reason to forget
about testing errno against sys_nerr in elog() ...

All relevant standards discourage use of sys_nerr too. There
was a discussion on cygwin lists once ... *searching*

in <http://cygwin.com/ml/cygwin/1999-11/msg00097.html&gt;

From: "J. J. Farrell" <jjf at bcs dot org dot uk>

[ about using sys_nerr & sys_errlist ]

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.

...

--
marko

What I've done to solve the immediate C++ problem is to take the
declaration of sys_nerr out of c.h entirely, and put it into the
two C modules that actually need it. However, I'm still wondering
whether we should not drop the rangecheck on errno completely.

One interesting thing I discovered while wandering the web is that
on at least some flavors of Windows, there are valid negative values
of errno --- which our code will not convert to a useful string,
as it stands...

regards, tom lane

On Sat, Jan 20, 2001 at 08:06:51PM -0500, Tom Lane wrote:

What I've done to solve the immediate C++ problem is to take the
declaration of sys_nerr out of c.h entirely, and put it into the
two C modules that actually need it. However, I'm still wondering
whether we should not drop the rangecheck on errno completely.

Probably not useful, but in our <errno.h>, sys_nerr is defined

#if !defined(_ANSI_SOURCE) && !defined(_POSIX_C_SOURCE) && \
!defined(_XOPEN_SOURCE)

P