signal & sigvec error return codes

[Doug Gwyn]

In article <10287 at socslgw.csl.sony.JUNET> diamond at csl.sony.junet (Norman Diamond) writes:
>In article <8044 at batcomputer.tn.cornell.edu> lijewski at batcomputer.tn.cornell.edu (Mike Lijewski) writes:
>In order to do this test properly, maybe it is necessary to cast the
>result of signal to an (int), and compare to -1.

No!  The same problem arises on UNIX systems where the result of sbrk()
is being tested.  These functions return error indications that, when
they can be expressed in C at all, have the form ((some_pointer)-1).
That is what you should test for; not all implementations permit
pointers to be cast to ordinary (int).

The real solution is for some system header to define a macro, like
SIG_ERR, for use in performing such tests in your application source.
On some architectures the value of such a macro may have nothing to
do with "-1" in any form.  SIG_ERR can always be implemented, e.g.:
	/* <signal.h>: */
	/* ... */
	extern void __dummy(int);	/* in C run-time library */
	#define SIG_ERR __dummy

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

The C Standard certainly does not require that an arbitrary integer
can be successfully cast to a pointer.  The rules for when this works
and when it doesn't are up to the implementation.  Many byte-addressable
architecture implementations of C permit casting arbitrary integers to
pointers, although an attempt to actually access a function or object
via a garbage pointer value may very well fail.