Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000327 [1003.1(2008)/Issue 7] Base Definitions and Headers Objection Error 2010-10-01 22:33 2013-04-16 13:06
Reporter eblake View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Eric Blake
Organization Red Hat
User Reference ebb.time_t
Section <sys/types.h>
Page Number 399
Line Number 13420
Interp Status Approved
Final Accepted Text See note Note: 0000561
Summary 0000327: time_t should be integral
Description If I'm interpreting history correctly, when time_t was originally
standardized, it was allowed to be floating point for two reasons, even
though all implementations at the time used an integer:
1. to allow a future implementation to provide a QoI improvement where
interfaces like stat() could provide sub-second resolution
2. to allow a future implementation to use IEEE double-precision in order to
get 54-bits of integral accuracy instead of 32-bits, before 64-bit integers
were common, in order to avoid the year 2038 wraparound limitation

However, both of these aspects have been overcome by history:
1. POSIX 2008 now requires that stat() return struct timespec, so that the
fractional portion of a timestamp is represented in tv_nsec; and has added
other interfaces like utimensat() that act on struct timespec for full
precision of timestamps
2. POSIX 2008 now requires 64-bit integers for _POSIX_V7_ILP32_OFFBIG, which
is pretty common for 32-bit hosts these days; and obviously 64-bit hosts
support 64-bit integers

Not all conformant systems have converted to a 64-bit time_t yet (in fact,
using a 64-bit OS with 32-bit time_t is still all too common), so the standard
must still allow 32-bit time_t, and portable code must be aware of this.
However, I am unaware of any compliant system that has actually implemented a
floating-point time_t, even though the standard allows it; and the mere fact
that the standard allows a weirdnix implementation with floating-point time
leads to some awkward portability constraints, that would otherwise be
avoidable. For example, the standard is silent on whether
(time_t)(uintmax_t)st.st_atime must be equal to st.st_atime. If they need
not be equal (because time_t is floating point, and the value contained a
fraction), then how does that fraction interact with the st.st_atim.tv_nsec
portion of the timestamp?

Additionally, the standard itself has non-normative statements that conflict
with the normative requirement that floating-point time_t be allowed, such as
line 68373 ("Since the utimbuf structure only contains time_t variables and
is not accurate to fractions of a second").

Therefore, in light of recent API additions in POSIX 2008 and in light of
existing implementation practice, it makes sense to tighten the standard,
and require that time_t be integral. This is tighter than required by C99,
but is not the first time that POSIX has imposed additional constraints
beyond the C standard (think of NULL, for example).

There are a few remaining APIs that might deserve struct timespec handling,
for uniform sub-second time-tracking, but these can be saved for separate bug
report(s):
<sys/msg.h> defines msqid_ds using only time_t
<sys/sem.h> defines semid_ds using only time_t
<sys/shm.h> defines shmid_ds using only time_t
difftime() takes time_t but returns double, meaning it cannot represent the
difference between all possible 64-bit time_t
Desired Action At line 13420 (XBD <sys/types.h>) change:

time_t and clock_t shall be integer or real-floating types.

to:

clock_t shall be an integer or real-floating type.
<CX> time_t shall be an integer type.</CX>

At line 18867 (XSH 2.12.1 Defined Types) change:

time_t Integer or real-floating type used for time in seconds, as defined in
the ISO C standard.

to:

time_t Integer type used for time in seconds, as defined in the ISO C standard.

At line 115844 (XRAT A.4.15 Seconds Since the Epoch) change:

The data size for time_t is as per the ISO C standard definition, which is
implementation-defined.

to:

This standard requires that time_t be an integer type with
implementation-defined size, but does not mandate a particular size. The
requirement that time_t be integral is an additional constraint beyond the
ISO C standard, which allows a real-floating time_t. Implementation practice
has shown that much existing code is unprepared to deal with a floating-point
time_t, and that use of struct timespec is a more uniform way to provide
sub-second time manipulation within applications.
Tags c99, tc1-2008
Attached Files

- Relationships
related to 0000577Closedajosey C11 and POSIX fall into disagreement regarding clock_t and time_t 

-  Notes
(0000561)
Don Cragun (manager)
2010-10-07 15:29
edited on: 2010-10-28 15:16

THE "DEFECT" SITUATION (i.e. the balloting group appears to have gotten it wrong):
Interpretation response
------------------------
The standard states that time_t is allowed to be a floating type, and conforming applications must conform to this. However, concerns have been raised about this which are being referred to the sponsor.

Rationale:
-------------
Although time_t is allowed to be a floating type, all known implementations use an integral type and many applications assume that it is an integral type. Therefore, the C requirement is being strengthened in this standard.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
Implement the desired action.

(0000598)
ajosey (manager)
2010-11-04 14:52

Interpretation proposed. Comments due back by December 4th 2010

- Issue History
Date Modified Username Field Change
2010-10-01 22:33 eblake New Issue
2010-10-01 22:33 eblake Status New => Under Review
2010-10-01 22:33 eblake Assigned To => ajosey
2010-10-01 22:33 eblake Name => Eric Blake
2010-10-01 22:33 eblake Organization => Red Hat
2010-10-01 22:33 eblake User Reference => ebb.time_t
2010-10-01 22:33 eblake Section => <sys/types.h>
2010-10-01 22:33 eblake Page Number => 399
2010-10-01 22:33 eblake Line Number => 13420
2010-10-01 22:33 eblake Interp Status => ---
2010-10-05 14:53 nick Tag Attached: c99
2010-10-07 15:22 Don Cragun Status Under Review => Resolved
2010-10-07 15:22 Don Cragun Resolution Open => Accepted
2010-10-07 15:22 Don Cragun Desired Action Updated
2010-10-07 15:23 Don Cragun Tag Attached: issue8
2010-10-07 15:24 Don Cragun Tag Attached: tc1-2008
2010-10-07 15:24 Don Cragun Tag Detached: issue8
2010-10-07 15:29 Don Cragun Interp Status --- => Pending
2010-10-07 15:29 Don Cragun Note Added: 0000561
2010-10-07 15:29 Don Cragun Status Resolved => Interpretation Required
2010-10-07 15:30 Don Cragun Final Accepted Text => See note Note: 0000561
2010-10-07 15:30 Don Cragun Resolution Accepted => Accepted As Marked
2010-10-28 15:16 Don Cragun Note Edited: 0000561
2010-11-04 14:52 ajosey Interp Status Pending => Proposed
2010-11-04 14:52 ajosey Note Added: 0000598
2010-12-09 16:23 ajosey Interp Status Proposed => Approved
2012-06-14 16:32 eblake Relationship added related to 0000577
2013-04-16 13:06 ajosey Status Interpretation Required => Closed


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