UNIX03 & C99 issue with 5.8.2
Alan Burlison
UNIX03 branding, and I'm getting compilation problems with 5.8.2, as the
compiler is considerably stricter than the old version. The issue all comes
down to how various #inludes are guarded, for example:
#if !defined(NSIG) || defined(M_UNIX) || defined(M_XENIX)
#include <signal.h>
#endif
I'm not sure where M_UNIX is supposed to be defined, but it isn't defined
anywhere in the Solaris source tree, or in the perl source - I suspect it
may be a gcc-ism. The only likely-looking symbols defined by the compiler are:
__STDC__
sun=1
__sun=1
__SVR4=1
unix=1
__unix=1
Of those I guess 'unix' is the one to go for, so I'm proposing to add that
to the appropriate #include guards. Does anyone know if this will cause any
problems and/or where the M_UNIX macro is supposed to be defined?
--
Alan Burlison
--
Rafael Garcia-Suarez
We'll see -- I added defined(__unix) to the list of conditions as change
#21883 to bleadperl.
Alan Burlison
>>Of those I guess 'unix' is the one to go for, so I'm proposing to add that
>>to the appropriate #include guards. Does anyone know if this will cause any
>>problems and/or where the M_UNIX macro is supposed to be defined?
>
> We'll see -- I added defined(__unix) to the list of conditions as change
> #21883 to bleadperl.
Configure seems to assume that it has signal.h anyway - I suspect if it
isn't available you wouldn't get Configure to complete. I think the correct
fix is probably to rip out all the guards around signal.h, not add more.
The following list of per-machine/os/compiler #defines is also a useful
reference: http://predef.sourceforge.net/
--
Alan Burlison
--
Alan Burlison
> Configure seems to assume that it has signal.h anyway - I suspect if it
> isn't available you wouldn't get Configure to complete. I think the
> correct fix is probably to rip out all the guards around signal.h, not
> add more.
I've checked, and with no signal.h available, six of the 'try.c' Configure
tests fail and eventually Configure hangs in the section that tries to
figure out the signal names. As signal.h appears to be a prerequisite for
Configure, I therefore suggest all the guards around the #includes of
signal.h should be removed - if I don't hear any objections I'll commit a
change to this effect over the weekend.
--
Alan Burlison
--
H.Merijn Brand
How about checking *if* there actually is a signal.h, and if there is none,
create an empty one, so the guards can safely be removed anyway.
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0, & 5.9.x, and 806 on HP-UX 10.20 & 11.00, 11i,
AIX 4.3, SuSE 8.2, and Win2k. http://www.cmve.net/~merijn/
http://archives.develooper.com/daily...@perl.org/ per...@perl.org
send smoke reports to: smokers...@perl.org, QA: http://qa.perl.org
Nicholas Clark
> How about checking *if* there actually is a signal.h, and if there is none,
> create an empty one, so the guards can safely be removed anyway.
Which are the 4 header files that even non-hosted implementations of C89
must have?
[IIRC WinCE didn't have one of the headers outside those 4]
Does WinCE have signal.h?
If signal.h is one of the 4, then I'd be quite happy to say "sorry" and
bail out if it is missing.
Nicholas Clark
Alan Burlison
> How about checking *if* there actually is a signal.h, and if there is none,
> create an empty one, so the guards can safely be removed anyway.
Creating a dummy one will just make it fail in a different place, it needs a
valid signal.h.
--
Alan Burlison
--
Nick Ing-Simmons
>We've just switched to a C99-compliant compiler and added the stuff for
>UNIX03 branding, and I'm getting compilation problems with 5.8.2, as the
>compiler is considerably stricter than the old version. The issue all comes
>down to how various #inludes are guarded, for example:
>
>#if !defined(NSIG) || defined(M_UNIX) || defined(M_XENIX)
>#include <signal.h>
>#endif
>
>I'm not sure where M_UNIX is supposed to be defined, but it isn't defined
>anywhere in the Solaris source tree, or in the perl source - I suspect it
>may be a gcc-ism. The only likely-looking symbols defined by the compiler are:
My guess is that Unix is expected to #define NSIG and this is a duplicate
include guard.
Nick Ing-Simmons
I am reasonably sure that is a multi-include guard to avoid re-define warnings
for
#include <signal.h>
...
#include <perl.h>
With the assumption that NSIG is only #defined in signal.h,
and that M_UNIX (whatever that might be) and M_XENIX break that
assumption.
What is #define-ing NSIG in your case?
#if !defined(NSIG) || defined(M_UNIX) || defined(M_XENIX)
#include <signal.h>
#endif
>
>--
>Alan Burlison
Nick Ing-Simmons
I still think that is a multi-include guard...
>
>Nicholas Clark
Chip Salzenberg
> #if !defined(NSIG) || defined(M_UNIX) || defined(M_XENIX)
M_UNIX and M_XENIX are SCOisms. (Don't hiss, this is the *old* SCO,
currently named Tarantella; they're not evil, just incompetent.)
M_XENIX indicates a SCO Xenix product; M_UNIX is for the SCO Unix
products, which in my time with them were all based on SVR3 (e.g. COFF).
I suspect that the "M_" prefix dates from Xenix's origins in Microsoft.
--
Chip Salzenberg - a.k.a. - <ch...@pobox.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
Paul Green
> My guess is that Unix is expected to #define NSIG and this is
> a duplicate include guard.
By the way, NSIG is not in POSIX-96 or POSIX-2001. I could not find a way
to get an equivalent value in either edition of POSIX. (You can get the
number of realtime signals, but that's a horse of a different color).
I believe that signal.h is required by C-1990 and later, and certainly by
POSIX. So I also support removing the guards. I also believe the standards
require that an implementation permit a header to be included multiple times
without ill effects.
While it probably doesn't apply here, I prefer having Configure contain this
mumbo-jumbo, and keeping the source files clean. It is much easier to deal
with OS-dependencies in one place, than to have to track them down file by
file.
Thanks
PG
--
Paul Green, Senior Technical Consultant,
Stratus Technologies, Maynard, MA USA
Voice: +1 978-461-7557; FAX: +1 978-461-3610
Alan Burlison
> I still think that is a multi-include guard...
The NSIG bit may be OK as it is defined in signal.h, but the M_UNIX and
M_XENIX bits aren't, and the net effect of those bits is to ensure that
signal.h is only included on the platforms that define them - which as far
as I can tell means that we only ever include signal.h for some SCO OSs.
The M_UNIX and M_XENIX bits should therefore be removed.
The header files on any modern OS *should* be self-guarding, so I'd maintain
that no guards should be required, which means the NSIG bit could go as well.
We probe for lots of header files already in Configure (i.e. all the i_xxx
entries in Porting/Glossary), so perhaps we should do the same for signal.h,
with the added step of bailing out from Configure if we don't find it, as if
it isn't there Configure will fail anyway.
--
Alan Burlison
--
Nick Ing-Simmons
>Nick Ing-Simmons [mailto:ni...@ing-simmons.net] wrote:
>> My guess is that Unix is expected to #define NSIG and this is
>> a duplicate include guard.
>
>By the way, NSIG is not in POSIX-96 or POSIX-2001.
>
>mumbo-jumbo, and keeping the source files clean. It is much easier to deal
>with OS-dependencies in one place, than to have to track them down file by
>file.
I think we all agree that is better way to do it.
For the line to be causing a problem for Alan though something _else_
is #defining NSIG and so inhibiting inclusion of signal.h
Nick Ing-Simmons
>Nick Ing-Simmons wrote:
>
>> I still think that is a multi-include guard...
>
>The NSIG bit may be OK as it is defined in signal.h, but the M_UNIX and
>M_XENIX bits aren't, and the net effect of those bits is to ensure that
>signal.h is only included on the platforms that define them - which as far
>as I can tell means that we only ever include signal.h for some SCO OSs.
>The M_UNIX and M_XENIX bits should therefore be removed.
Back at //depot/perl/unixish.h#1 i.e. perl5.003 it looked like:
#if !defined(NSIG) || defined(M_UNIX) || defined(M_XENIX)
# include <signal.h>
#endif
//depot/maint-5.8/... seems to have :
unixish.h:#if !defined(NSIG) || defined(M_UNIX) || defined(M_XENIX) || defined(__NetBSD__) || defined(__FreeBSD__) || defined(__OpenBSD__)
Which is getting silly - this is _unixish_ - so of course it has signal.h
>
>The header files on any modern OS *should* be self-guarding, so I'd maintain
>that no guards should be required, which means the NSIG bit could go as well.
Let us try it and see.
I seem to recall the NSIG thing was added for the non-modern SunOS4.
('twas a long time ago... I may be mis-remembering.)
I suspect all the rest of the stuff is just cargo-cult.
>
>We probe for lots of header files already in Configure (i.e. all the i_xxx
>entries in Porting/Glossary), so perhaps we should do the same for signal.h,
>with the added step of bailing out from Configure if we don't find it, as if
>it isn't there Configure will fail anyway.
I agree we need signal.h - so not including seems pointless.
Alan Burlison
> For the line to be causing a problem for Alan though something _else_
> is #defining NSIG and so inhibiting inclusion of signal.h
After an amount of digging I've nailed this down. On Solaris at least, NSIG
is defined in <sys/signal.h> rather than <signal.h>, so using it as a guard
for <signal.h> was never correct in the first place. However, that still
doesn't explain why this wasn't a problem in the past, and now is a problem
that the UNIX03 (AKA SUSv3) changes have gone in. The include tree for
<sys/signal.h> as used in doio.c is:
perl.h
<sys/types.h>
<sys/select.h>
<sys/signal.h>
<sys/types.h> includes <sys/select.h> because:
/*
* Nested include for BSD/sockets source compatibility.
* (The select macros used to be defined here).
*/
Which hasn't changed. What *has* changed is that <sys/select.h> now
includes <sys/signal.h>. This in turn is because UNIX03 adds a new library
function, pselect(), which has the following prototype:
int pselect(int nfds, fd_set *readfds, fd_set *writefds, fd_set *errorfds,
const struct timespec *timeout, const sigset_t *sigmask);
Hence the problem, as pselect() requires the definition of sigset_t from
<sys/signal.h>. I expect that we will see this problem on other platforms
as other vendors make the necessary changes to become UNIX03 compliant.
I've ripped out *all* the #ifdef ... #endif mumbo-jumbo around the #includes
of <signal.h> and everything works just fine, at least on the platform I
care about most ;-) I'll sumbit a patch to this effect to blead in the morning.
Thanks to everyone for their help and suggestions.
--
Alan Burlison
--