|
Home About Us A-Z Index Search * Contact Us Register Login Press ShopThe Open Brand -- Problem Reporting and Interpretations System |
Problem Report 2029 Details
Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges
This page provides all information on Problem Report 2029.
Report 2029 Actions
Problem Report Number 2029 Submitter's Classification Specification problem State Resolved Resolution Temporary Interpretation (TIN) Problem Resolution ID TIN.X.0090 Raised 1970-01-01 08:00 Updated 2003-03-13 08:00 Published 1998-03-03 08:00 Product Standard Internationalised System Calls and Libraries Extended V2 (UNIX 98) Certification Program The Open Brand certification program Test Suite VSTH version 5.1.2 Test Identification PTHR.hdr/misc/pthread 5 Specification System Interfaces and Headers Issue 5 Location in Spec See Problem Text Problem Summary TIN5TH.00001 (pthread.h includes time.h, POSIX should allow symbols defined in signal.h to be visible in the namespace when time.h is included). The Base Working Group recommends a TIN on this issue while a PASC I... Problem Text
(pthread.h includes time.h, POSIX should allow symbols defined in
signal.h to be visible in the namespace when time.h is included).
The Base Working Group recommends a TIN on this issue
while a PASC Interpretation request is filed with the
recommendation that POSIX.1 allow the symbols in the <signal.h>
header to be visible when the <time.h> header is included.
Note in this implementation sys/siginfo.h is included by signal.h.
The text of the request to be put forward to POSIX
follows:
Interp 1.
time.h should allow inclusion of signal.h
-------------------------------------------
Although the synopsis for timer_create() (POSIX.1-1996, P312, L138-141)
shows that <signal.h> must be included before <time.h> to pick up the
definition of struct sigevent, there are lots of synopses in
POSIX.1-1996 that just specify <time.h>. When an application using
routines defined in <time.h> that don't also require <signal.h> (e.g.
clock_gettime()) is built, most compilers generate warnings about a
dubious tag declaration for struct sigevent. This is because the
specification for <time.h> does not require (or even allow) struct
sigevent (and the union sigval needed to define its
sigev_notify_function element) to be defined and does not reserve
namespace to define elements of struct sigevent and union sigval when
<time.h> is included. Even though these are warnings, not errors, our
customers complain when they use standard functions from standard
headers and don't get "clean compiles".
In other places where this problem could occur, the C Standard and
POSIX standards usually reserve the namespace or require that the
needed elements be in both headers. Examples of these are:
1. The description of <stdio.h> in the C Standard (ISO/IEC 9899-1990),
P124, Section 7.9.1, 2nd and 3rd paragraphs requires that <stdio.h>
define size_t and NULL in <stdio.h> as well as in <stddef.h>.
2. The description of <mqueue.h> in POSIX.1-1996, P319, L2-4 says that
including <mqueue.h> may essentially include <sys/types.h>,
<fcntl.h>, <time.h>, and <signal.h> and L13-16 requires that struct
sigevent be defined in <mqueue.h> as well as in <signal.h>.
Was the intent here to require warnings about dubious structure tags
for conforming applications using <time.h>, but not using
timer_create()? Or, was it an oversight that the description of
<time.h> did not specify that implementations were allowed to include
<signal.h> as a side effect of including <time.h>?
================================================================================
We propose the following solution:
================================================================================
Add to the end of the paragraph on POSIX.1-1996, P309, L2-3
(description of <time.h>):
Inclusion of the <time.h> header may make visible symbols
allowed by this part of ISO/IEC 9945 to be in the <signal.h>
header.
================================================================================Test Output
************************************************************************
/tset/PTHR.hdr/misc/pthread_5/T.pthread_5 2 Failed
Test Description:
If the feature test macro _POSIX_C_SOURCE is defined to have
at least the value 199506L:
no symbols other than those beginning with pthread_ or PTHREAD_
shall be visible.
Posix Ref: Component PTHREAD Assertion 9945-1:1996 2.7.2-2(C)
Test Information:
Compilation exited with non-zero value when expected to succeed
Feature test macros: -D_XOPEN_SOURCE=500
Compiler or run-time messages or results:
"/usr/include/sys/siginfo.h", line 27: syntax error before or at:
"sival_int unprotected"
"/usr/include/sys/siginfo.h", line 27: warning: syntax requires ";"
after last struct/union member
"/usr/include/sys/siginfo.h", line 29: zero-sized struct/union
"/usr/include/sys/siginfo.h", line 55: syntax error before or at:
"sigev_notify unprotected"
"/usr/include/sys/siginfo.h", line 55: warning: syntax requires ";"
after last struct/union member
"/usr/include/sys/siginfo.h", line 59: zero-sized struct/union
"/usr/include/sys/siginfo.h", line 60: syntax error before or at:
"sigev_value unprotected"
"/usr/include/sys/siginfo.h", line 60: warning: syntax error: empty
declaration
"/usr/include/sys/siginfo.h", line 64: syntax error before or at: }
"/usr/include/sys/siginfo.h", line 64: warning: syntax error: empty
declaration
"/usr/include/sys/siginfo.h", line 216: syntax error before or at:
"si_signo unprotected"
"/usr/include/sys/siginfo.h", line 216: warning: syntax requires ";"
after last struct/union member
"/usr/include/sys/siginfo.h", line 237: zero-sized struct/union
"/usr/include/sys/siginfo.h", line 243: syntax error before or at: }
"././ALLOW.h", line 95: cannot recover from previous errors
c89: acomp failed for cc02es.c
Compilation exited with non-zero value when expected to succeed
TEST INFORMATION TRUNCATED BY -t OPTION
***********************************************************************Review Information
Review Type SA Review Start Date null Completed null Status Complete Review Resolution Temporary Interpretation (TIN) Review Conclusion
A Temporary Interpretation is granted.
Problem Reporting System Options:
- View Report 2029
- List All PRs
- Search Reports
- Email the System Administrator
- View the The Open Brand Interpretations Database User Manual
Contact the Certification Authority