I've just round to looking at this discussion. Tony Finch said:
On Sat, 30 Jan 2010, Bill Seymour wrote:
On Sat, Jan 30, 2010 at 5:37 PM, Tony Finch <dot@dotat.at> wrote:
On Sat, 30 Jan 2010, Robert Elz wrote:
locatime() can return NULL these days, ...
This code follows the C standard, so this bug is a defect in the standard.
How so? It's not the job of the standard to specify coding practices. If a function can return a null pointer, programmers need to check for that.
The standard specifies the presence of the bug that Robert reported:
Section 7.23.3.2 para. 2:
The ctime function converts the calendar time pointed to by timer to local time in the form of a string. It is equivalent to
asctime(localtime(timer))
Section 7.23.3.4 para. 4:
The localtime function returns a pointer to the broken-down time, or a null pointer if the specified time cannot be converted to local time.
Section 7.23.3.1 specifies the behaviour of asctime() in terms of source code which does not check for a NULL argument.
The fact that localtime() can return NULL but neither ctime() nor asctime() checks for this is exactly the bug that Robert reported and proposed a fix for.
This situation happens when localtime is not able to convert the specified time to a broken-down time. This means that the notional broken-down time being supplied to asctime is nonsensical. WG14 has already decided (defect report 217) that asctime's behaviour is undefined if the input cannot be represented according to the given algorithm - for example, if the year is outside the range -999 to 9999. This is just another such situation. The answer - if anyone asked them - is likely to be that you shouldn't call ctime if you can't be sure it's representable. Nothing stops a given implementation making this work, but nothing requires it to either. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646