Austin Group Defect Tracker

Aardvark Mark III


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000659 [1003.1(2008)/Issue 7] Base Definitions and Headers Editorial Enhancement Request 2013-02-10 04:46 2013-05-03 12:20
Reporter dalias View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Interpretation Required  
Name Rich Felker
Organization musl libc
User Reference
Section sys/types.h
Page Number unknown
Line Number unknown
Interp Status Approved
Final Accepted Text Note: 0001463
Summary 0000659: Remove the requirement that timer_t be an arithmetic type
Description The text in the standard describing the contents of sys/types.h includes "All of the types shall be defined as arithmetic types of an appropriate length, with the following exceptions:". timer_t is not listed in the exceptions. As far as I can tell, there is no reason for timer_t to have arithmetic type; for all practical purposes, timer_t is an opaque handle. I suspect it was just omitted from the list of exceptions by mistake.

Making timer_t an arithmetic type would not be a major burden for new implementations, but at least one major implementation, the GNU C library, has timer_t defined as void *, and changing the definition seems undesirable from a standpoint of maintaining a stable C++ ABI.
Desired Action Add timer_t to the list of exceptions below the quoted text, so that implementations where timer_t has non-arithmetic type will no longer be non-conforming.

Possibly also add text requiring timer_t to have scalar type, if it is desirable to allow applications to print timer_t values by casting to uintmax_t or similar.
Tags tc2-2008
Attached Files

- Relationships

-  Notes
(0001461)
geoffclare (manager)
2013-02-11 10:44

I agree that omission of timer_t from the list of types that need not
be arithmetic types is likely the result of an oversight. However, it
should be noted that if we remove all restrictions on the types
allowed for timer_t then we should also remove all of the "may fail"
EINVAL errors for invalid timer_t values. There should instead be a
statement that the behaviour is undefined and some rationale, similar
to what we did for invalid pthread_attr_t values.
(0001463)
geoffclare (manager)
2013-02-15 09:59

Interpretation response
------------------------
The standard states that timer_t is an arithmetic type, and conforming
implementations must conform to this. However, concerns have been
raised about this which are being referred to the sponsor.

Rationale:
-------------
It appears that this requirement may be an accident of the way timer_t
was added to POSIX.1 via the .1b amendment.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------

At page 399 line 13408 add timer_t to the list of exceptions to the
arithmetic types requirement.

At page 400 line 13438 add timer_t to the list of types that have no
comparison or assignment operators.

Cross-volume changes to XSH...

At page 2113 line 66876 section timer_delete() add a new paragraph to
the end of the DESCRIPTION:

    The behavior is undefined if the value specified by the timerid
    argument does not correspond to a timer ID returned by
    timer_create() but not yet deleted by timer_delete().

At page 2113 line 66881-66882 section timer_delete() replace the
entire ERRORS section with:

    No errors are defined.

At page 2113 line 66888 section timer_delete() change the RATIONALE
section from:

    None.

to:

    If an implementation detects that the value specified by the
    timerid argument to timer_delete() does not correspond to a
    timer ID returned by timer_create() but not yet deleted by
    timer_delete(), it is recommended that the function should fail
    and report an [EINVAL] error.

At page 2115 line 66956 section timer_getoverrun() add a new
paragraph to the end of the DESCRIPTION:

    The behavior is undefined if the value specified by the timerid
    argument to timer_getoverrun(), timer_gettime(), or
    timer_settime() does not correspond to a timer ID returned by
    timer_create() but not yet deleted by timer_delete().

At page 2115 line 66968-66970 section timer_getoverrun() delete:

    These functions may fail if:

    [EINVAL] The timerid argument does not correspond to an ID
    returned by timer_create() but not yet deleted by timer_delete().

At page 2116 line 66997 section timer_getoverrun() add a new
paragraph to the end of the RATIONALE section:

    If an implementation detects that the value specified by the
    timerid argument to timer_getoverrun(), timer_gettime(), or
    timer_settime() does not correspond to a timer ID returned by
    timer_create() but not yet deleted by timer_delete(), it is
    recommended that the function should fail and report an [EINVAL]
    error.
(0001513)
ajosey (manager)
2013-03-29 08:04

Interpretation Proposed 29 Mar 2013
(0001583)
ajosey (manager)
2013-05-03 12:20

Interpretation approved 3 May 2013

- Issue History
Date Modified Username Field Change
2013-02-10 04:46 dalias New Issue
2013-02-10 04:46 dalias Status New => Under Review
2013-02-10 04:46 dalias Assigned To => ajosey
2013-02-10 04:46 dalias Name => Rich Felker
2013-02-10 04:46 dalias Organization => musl libc
2013-02-10 04:46 dalias Section => sys/types.h
2013-02-10 04:46 dalias Page Number => unknown
2013-02-10 04:46 dalias Line Number => unknown
2013-02-11 10:44 geoffclare Note Added: 0001461
2013-02-15 09:59 geoffclare Note Added: 0001463
2013-02-21 16:12 geoffclare Interp Status => Pending
2013-02-21 16:12 geoffclare Final Accepted Text => Note: 0001463
2013-02-21 16:12 geoffclare Status Under Review => Interpretation Required
2013-02-21 16:12 geoffclare Resolution Open => Accepted As Marked
2013-02-21 16:13 geoffclare Tag Attached: tc2-2008
2013-03-29 08:04 ajosey Interp Status Pending => Proposed
2013-03-29 08:04 ajosey Note Added: 0001513
2013-05-03 12:20 ajosey Interp Status Proposed => Approved
2013-05-03 12:20 ajosey Note Added: 0001583


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker