Document: N1895 - Updated TC for DR437
Submitter: Nick Stoughton (US)
Date: 2015-03-10

Defect Report #437

Summary

C11 (and C99 before it) state for clock() that

If the processor time used is not available or its value cannot be represented, the function returns the value (clock_t)(-1).

In order to measure the time spent in a program, the clock function should be called at the start of the program and its return value subtracted from the value returned by subsequent calls.

The normative requirement implies that if more processor time has passed than can be fit into a variable of type clock_t the function must fail and return (clock_t)-1.

However, existing implementations almost exclusively ignore this requirement and if more ticks pass than can fit into a clock_t the implementation simply truncates the value and return the lowermost bits of the actual value. In programming environments where clock_t is a 32-bit integer type and CLOCKS_PER_SEC is one million (a very common implementation), clock() will start misreporting in less than 36 minutes of processor time for signed clock_t, or 72 minutes for unsigned clock_t.

Question 1: Are such implementations conforming? If not, should the standard be altered in any way to permit this de-facto standard implementation?

Question 2: Should the standard define some limit macros for clock_t (effectively defining new values in limits.h for CLOCK_MAX, the minimum maximum value for a clock_t)?

Question 3: If the value is truncated and clock_t is a signed type, the recommended application usage n footnote 319 (subtracting clock_t values to measure intervals) can cause the application to invoke undefined behavior via integer overflow. In particular, if the initial call to clock() returned A > 0 (by virtue of some processor time having been consumed before the start of main() or the point of first measurement), and a subsequent call returned B=INT_MIN just after overflow, then the recommended practice of computing B-A invokes undefined behavior. Should there be any warning of this included in the footnote?

Suggested Change

Given that the vast majority of surveyed implementations appear to have implemented clock with a simple incrementing counter with no check for overflow, the requirement for clock() to return (clock_t)-1 when the number of clock ticks cannot be represented in a variable of type clock_t should be relaxed:

At 7.27.2.1 paragraph 3, change:

If the processor time used is not available or its value cannot be represented, the function returns the value (clock_t)(-1).

If the processor time used is not available, the function returns the value (clock_t)-1.

In order to measure the time spent in a program, the clock function should be called at the start of the program and its return value subtracted from the value returned by subsequent calls. Note, however, that such a subtraction may result in undefined behavior if clock_t is an unsigned integer type.

Committee Discussion

• This issue is tied to Austin Group Defect #686.
• The committee feels that the core issue regards required behavior under the condition that overflow occurs in the implementations choice for the representation of clock_t.
• It is noted that many and possibly most implementations have chosen an integer clock_t size that overflows early and often.
• The standard does seem to require that the overflow condition is detected and that the corresponding return value shall be that of failure (clock_t)-1.
• Such detection runs counter to the desired behavior of the clock counter as being that of highest implementation efficiency, and to subsequent uses across durations that do not exhibit overflow after the first occurrence.
• The suggested technical corrigendum does not appear to discuss or address this core issue and warrants further discussion. The following suggestion for the footnote is offered:

  Implementations commonly use an integer clock_t type that can overflow in as little as 36 minutes. All uses of clock() to measure a duration of time must address the issue of possible overflow.

Apr 2014 meeting

Committee Discussion

The author will be solicited for a revised technical corrigendum.

Updated Technical Corrigendum

If the processor time used is not available or its value cannot be represented, the function returns the value (clock_t)(-1).

If the processor time used is not available, the function returns the value (clock_t)-1. If the value of the processor time used cannot be represented in a variable of type clock_t, it is implementation defined whether the implemetation returns (clock_t)-1 or truncates the time to fit into the variable.

In order to measure the time spent in a program, the clock function should be called at the start of the program and its return value subtracted from the value returned by subsequent calls. Implementations commonly use an integer clock_t type that can overflow in as little as 36 minutes. All uses of clock() to measure a duration of time should address the issue of possible overflow, noting that a simple subtraction may result in undefined behavior if clock_t is an unsigned integer type.