Usenet 1994 October/usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso/std_unix/volume.31/text0062.txt

Text File | 1993-07-15 | 1.8 KB | 37 lines

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (James Buster) writes:
>More importantly, the N argument signal handler (where N > 1) and
>event handlers from 1003.4 destroy any hope of strict ANSI C
>compatibility.

The real problem is that extra arguments for the same class of functions
that signal() is expected to register for later invocation cannot be
supported on all possible platforms.  This kind of problem is why we
have special <stdarg.h> implementation-provided support for variable-
argument functions, and why X3J11 had to choose between variadic
signal handler function type and one-int argument signal handler
function type (the latter is what was chosen).  I think people have
gotten too used to sloppy programming on systems that let one get
away with it, so that they don't understand why this is a real issue.

>Actually, while I'm talking about implementation defined behavior,
>what about the 1003.4a functional interface for threads and the 1003.4
>events interface? They require that you be able to use a `void *' as data.
>One of the committee members told me that you are giving the caller a
>"pointers worth of data". In C, pointers do not, and never have,
>contained data. This strikes me as being totally bogus.

Actually the C standard requires that there be some integral type
capable of holding a (converted) object pointer such that it can
be converted back to a pointer (of the same type) and compare
equal to the original pointer value.  However, this does differ
from being able to stash an arbitrary integral value into a
pointer.  If one really needs to do that sort of thing, either the
pointer should be taken as pointing to the actual data or else a
union should be used.


Volume-Number: Volume 31, Number 65