[Python-Dev] ANSIfication problems: signalmodule.c doesn't compile

Tim Peters tim_one@email.msn.com
Sun, 23 Jul 2000 16:32:10 -0400


[Thomas Wouters]
> ...
> 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.

Yes, it is.  Almost nothing *else* about signals is defined to work in a
portable way, but handlers are defined to return void.

> 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.

I don't really care about extra crap in the configure scripts, except to the
extent that they baffle people porting to new platforms (the Talmudic
distinctions drawn to support 197 incompatible flavors of Unix leave people
on other systems scratching their heads until the earlier of wearing their
fingernails away or passing out from blood loss <wink>).

What I *really* care about is getting RETSIGTYPE out of our *source* code.
Macros do damage!  They're hard to figure out, hard to write safely, full of
surprises even so, and frustrate the heck out of single-stepping in the
debugger.  Unforunately, they're necessary to write robust cross-platform C
code.  But every one we can nuke is one less knife in the heart.

Hmm ... I'll leave the Unix config stuff alone, but get rid of RETSIGTYPE in
the rest of the tree.  Objections?