Clive D.W. Feather
clive at demon.net
Thu Jul 29 14:52:46 UTC 2004
Robert Elz said:
> I agree with that, though I suspect my interpretation of "valid"
> might be different than yours. I'd prefer to always return a
> string that fits exactly in a 26 byte buffer, with the \n in buf
> and \0 in buf, and every other character posit position occupied
> by exactly what is supposed to be there (the colons at known offsets,
The problem is that the only specification for "exactly what is supposed to
be there" is what's in the standard.
> If that makes the output be "incorrect" when the input struct
> tm contains values (way) beyond those which asctime() was designed to
> handle, then that's just fine with me. Where we can handle the
> value, and retain the output format, we should however.
Assuming that all fields except the year are in range, then we have the
* Years 1000 to 9999 and -999 to -100: everyone agrees.
* Years before -999 or after 9999: undefined behaviour, so implementations
can do what they want.
* Years -99 to 999: the C standard says the string should be shorter, you
say the string should contain extra spaces or zeroes.
I don't believe that there has ever been a real expectation for that case.
I don't know the history of the asctime() specification, but I suspect that
it has more basis than your claim.
> People expecting (or who should be expecting) to deal with arbitrary
> struct tm values - or in fact, just about any current code expecting
> to convert times into strings ought to be using strftime,
People expecting an exact format for the output should be using strftime.
asctime() is a quick-and-dirty interface to produce something that can be
output in a log file or similar. It's not intended to be an exact science.
Clive D.W. Feather | Work: <clive at demon.net> | Tel: +44 20 8495 6138
Internet Expert | Home: <clive at davros.org> | Fax: +44 870 051 9937
Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc | |
More information about the tz