On 12/6/2012 9:25 AM, Anders Wegge Keller wrote:

>

> According to the C2011 draft I have available, the values in the

> struct tm, passed to mktime(), are not restricted to the normalized

> ranges. (2.27.2.3 §2).
ITYM 7.27.2.3.

> Is this to be taken literally,
That's the usual way to take normative text ...

> such that any combination of values in

> the tm struct, that corresponds to something that can be expressed in

> a time_t is a valid input?
Yes, keeping in mind that time_t's range is implementation-

defined (7.27.1p4). If the tm_xxx values correspond to a time_t

value in that implementation-defined range, 7.27.2.3p3 requires

mktime() to return that time_t value.

Clearly, the intent is to relieve the programmer of the burden

of all that date arithmetic. If you've got a struct tm representing

some time T and you want to determine the time at T plus 01:23:45,

you can blithely add 1*3600+23*60+45 to the tm_sec field and call

mktime(), and mktime() will figure things out.

> As I read the following paragrahp, that seem to be the case. Which

> lead me to think of exxtreme cases like tm_sec, tm_min, tm_hour,

> tm_mday and tm_mon all at INT_MAX, and tm_year set to a sufficiently

> large negative value.

>

> Am I missing something, or would a conforming implementation have to

> handle this?
I think so. The only out I can imagine is that if mktime()

cannot determine whether Standard or Daylight time prevails, it

may be unable to find "the" corresponding time_t value and could

then return (time_t)-1 to indicate failure. But if the question

boils down to "Must mktime() be careful about overflow in its

internal computations?" I think the answer must be "Yes."

--

Eric Sosman

http://www.velocityreviews.com/forums/(E-Mail Removed)d