Home • About Us • A-Z Index • Search * Contact Us • Register • Login • Press • Shop

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 1633 Details

Help Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges

This page provides all information on Problem Report 1633.

Report 1633 Actions

    Problem Report Number 1633
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Permanent Interpretation (PIN)
    Problem Resolution ID PIN.X.0190
    Raised 1998-04-23 08:00
    Updated 2003-03-13 08:00
    Published 1998-05-18 08:00
    Product Standard Internationalised System Calls and Libraries Extended V2 (UNIX 98)
    Certification Program The Open Brand certification program
    Test Suite VSU version 5.0.2
    Test Identification CAPI.os/procprim/sigaction 25
    Specification System Interfaces and Headers Issue 5
    Location in Spec See Problem Text
    Problem Summary PIN4U.00056 This is a duplicate of PG4U.00086.
    Problem Text
    We believe the test to be in error.

    PG4U.0067 (rejected) states, in the Consultant's rationale:
    "The si_status field of the siginfo_t type infop structure is described
    in <signal.h>, page 797 as follows:

    int si_status exit value or signal

    The exit() spec defines the exit value as the low order 8 bits
    of the status argument. This is what must be placed in the si_status
    member."


    We agree with this, but cannot then understand the rejection of PG4U.0086,
    where the Consultant states:

    "The exit() description specifies that only lower eight bits of the
    value passed to exit are made available, but it only applies when
    various wait*() functions are being executed:"

    this statement is supported *nowhere* in the specification. The specification
    for si_code says "exit value", and "exit value" is defined to be an
    8-bit range in the exit() specification. Certainly there is other status
    made available in the "status" returned to wait(), etc., but the only value
    mentioned for si_code is "exit value", which has an explicit definition.
    This definition does not include values above 255.
    Test Output
    TEST CASE: sigaction

    TEST PURPOSE #25
    After a call to int sigaction(int sig, const struct
    sigaction *act, struct sigaction *oact) with
    SA_SIGINFO set in the sa_flags member of the sigaction
    structure pointed to by act and sig equal to SIGCHLD,
    on entry to the signal catching function specified by
    the sa_sigaction member when the child exited the
    si_code member of the structure pointed to by the
    siginfo argument shall contain CLD_EXITED, the si_pid
    member shall contain the child process ID, the
    si_status member shall contain the child's exit value
    and the si_uid member shall contain the real
    user ID of the process that sent the signal.
    PREP: Set up action for SIGCHLD
    PREP: fork() a child that exits normally
    TEST: signal = SIGCHLD
    TEST: si_code = CLD_EXITED
    TEST: si_status = exit value
    ERROR: si_status incorrect. Expected 48879,Received 239
    25 FAIL

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    We recommend this request be refused. It is a duplicate of PG4U.00086

    The submitter is restating the argument raised in the originally refused
    request with no additional information to support changing the ruling.

    Again, the spec says for exit():

    The values of status can be EXIT_SUCCESS or EXIT_FAILURE, as
    described in <stdlib.h>, or any implementation-dependent value,
    although note that only the range 0 through 255 will be available
    to a waiting parent process.

    That is:

    - a process' exit value can be any value

    - the truncation of an exit value to an 8-bit quantity is specific to
    making this information available to a waiting process.

    A sigaction() call does not cause a parent process to wait nor does signal
    delivery. Thus the basic definition of exit value, any value that fits
    in an int, must apply for si_code.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    This request should go for a 14 day review as it is an appeal
    against a previous decision.

    The specification may be unclear on whether si_status contains the truncated
    exit value.

    Review Type Expert Group Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    The waiver should be granted.

    The third paragraph of the description of exit() (XSH5, P197) says:
    "... The values of status can be EXIT_SUCCESS or
    EXIT_FAILURE, as described in <stdlib.h>, or any
    implementation-dependent value, although note that only
    the range 0 through 255 will be available to a waiting
    parent process."

    The "any implementation-dependent value" allows an implementation to
    only accept EXIT_SUCCESS or EXIT_FAILURE.

    The exit status made available to the wait family of functions (wait(),
    wait3(), waitid(), and waitpid()) is truncated to the low order eight
    bits. (This is due to legacy 16-bit int systems and the need to indicate
    not only the exit status of a process that terminated normally, but also
    other causes for process status changes [stopped, resumed, terminated
    abnormally with core dump, ...].) The exit status made available through
    the siginfo_t passed to a signal handler installed with sigaction()
    with the SA_SIGINFO flag does not have this problem. (It has a full int
    available for the exit status status of the process or the signal that
    caused it to change state and separate fields to specify the process's
    state change.)

    This wording should be reviewed in the next revision of the specification.


    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Permanent Interpretation (PIN)
    Review Conclusion
    A Permanent Interpretation is granted.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority