[Python-Dev] ANSIfication problems: signalmodule.c doesn't compile
Sun, 23 Jul 2000 22:16:35 +0200
On Sun, Jul 23, 2000 at 03:55:17PM -0400, Tim Peters wrote:
> [Thomas Wouters]
> > As for the other point, I'd say drop the support for
> > 'int'-returning systems altogether. If such systems are still
> > in use, they would've been generating warnings for a long time
> > now. Apparently noone noticed.
> The Unix(tm)-ish autoconfigure stuff came after my Unixish days, and I still
> don't have a Unixish system available so I've got scant idea how it works.
> >From what I can dope out, RETSIGTYPE isn't mentioned in configure.in at all,
> but gets pulled out of thin air by magic anyway by the time "configure" is
> echo "$ac_t""$ac_cv_type_signal" 1>&6
> cat >> confdefs.h <<EOF
> #define RETSIGTYPE $ac_cv_type_signal
Autoconf consists of standard and user-defined rules. The standard ones are
things like checking the availability of ANSI types, and usually consist of
a single m4 macro:
# Type availability checks
'AC_TYPE_SIGNAL' expands in those 40 lines of code in configure that check
the return type of signal handlers.
User-defined rules are like the one I wrote for right-shifting-zero-fills,
and are a tad longer: there are a few 'component' macros that check for
headers, functions or libraries, and you can write your own little
test-program to switch on. All the macros get expanded into a shell script
that compiles (and executes, when necessary) test programs.
> This *suggests* it's "still an issue" under Unixy things, but beats me.
> void is ANSI, int isn't. If any Unixoid swears it's OK to nuke RETSIGTYPE,
> I'd be delighted to do it.
configure is also built to run on any system with an almost-working K&R C
compiler and something remotely resembling proto-UNIX ;) It doesn't care
much about standards, because it's build in order to easily support systems
that *aren't* following the standards.
All in all, if the ANSI standard says signal-handlers should return void, by
all means, remove the switch altogether. I removed the whole
HAVE_STDARG_PROTOTYPES switch for ANSI variable-arg lists for exactly the
same reason. I just wasn't sure if the return type of signal handers was
defined by ANSI C.
In fact, we can probably remove a lot more checks from configure.in and the
code that #ifdefs on the result, if we decide to really eradicate every
trace of non-ANSI code. However, it's not winning anything more than a few
seconds of 'configure' time and a few milliseconds of 'cpp' time, so it's
probably not worth it.
Thomas Wouters <email@example.com>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!