Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.27/text0004.txt

Text File | 1992-05-20 | 1.5 KB | 40 lines

Submitted-by: [e-mail] (Chuck Karish)

In article <[e-mail]> [e-mail]
(Mike Wulkan) writes:
>Submitted-by: [e-mail] (Mike Wulkan)
>I have a question as to the intent of the following statement in section
>3.3.1.3 of 1003.1:
>
>  521 (c) The behavior of a process is undefined after it returns normally
>  522     from a signal-catching function for a SIGFPE, SIGILL, or SIGSEGV
>  523     signal that was not generated by the kill() function or the raise()
>  524     function defined by the C Standard {2}.
>
>Is the intent of Posix to "limit" the scope of "other
>implementation-defined value" to exactly SIGFPE, SIGILL and SIGSEGV?
>
>Or is Posix simply extending the list to include SIGILL and SIGSEGV
>while still allowing for other implementation-defined values?

SIGFPE, SIGILL, and SIGSEGV are the signal names defined by
POSIX.1 that correspond to computational exceptions.  Elsewhere
in POSIX.1 it is stated that the implemention may generate
other, implementation-defined signals.  The names of these
signals and the conditions under which they are generated
are to be documented in the POSIX conformance document.

POSIX.1 tries not to keep the implementation from providing
additional signals or errno values that give more information
to the programmer, as long as the base behavior specified
by the Standard is also supported and the appropriate
documentation is provided.


    Chuck Karish        [e-mail]
    Mindcraft, Inc.        [phone]


Volume-Number: Volume 27, Number 5