signal & sigvec error return codes

[Norman Diamond]

In article <8044 at batcomputer.tn.cornell.edu> lijewski at batcomputer.tn.cornell.edu (Mike Lijewski) writes:

>     Do all vendors still document the return code of signal and
>sigvec as being -1 (implicitly an int)?

Probably not -- but you do need to know that it is implicitly an int.

>My problem with this is
>that if you try to be a "good" programmer and check for an error as
>in 
>    if(signal(SIGINT, SIG_IGN) == -1){
>      perror("signal");
>      exit(1);
>    }
>say, you will either get a warning or an error, depending on how smart
>your compiler is.

In order to do this test properly, maybe it is necessary to cast the
result of signal to an (int), and compare to -1.  After all, the value
of an int does not have to be divisible by 4.  Though I still wonder,
since signal is returning a pointer to a function, how does signal get
a -1 into that address register without aborting (on some machines).

>Why not document the error return as being something
>along the lines of SIG_ERR, where SIG_ERR is defined as
>
>#define SIG_ERR ((int(*)())-1)
>
>in <signal.h>?

SIG_IGN has this definition in <signal.h>, last time I looked.  And
now, besides wondering how signal gets a wierd address into a certain
register, I also wonder how the cast does it in the compiled code.
Why doesn't the compiled code abort?  Why doesn't the compiler notice
that an odd address cannot be a function pointer?  In short, why does
this work?  (Also, does ANSI require such nonsense to work, does ANSI
require exceptions to be permitted to the usual rules for pointers,
or can <signal.h> define values that are at least aligned, even if not
guaranteed to be in a legal segment.....)

--
Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.co.jp at relay.cs.net)
  The above opinions are my own.   |  Why are programmers criticized for
  If they're also your opinions,   |  re-implementing the wheel, when car
  you're infringing my copyright.  |  manufacturers are praised for it?