[tz] proposed changes for Win32 and a improved mktime() algorithm

[Zefram]

Paul Eggert wrote:
>Thanks, I didn't know about this extension. However, it has undefined
>behavior in standard C, so we can't use it in code intended to be portable
>everywhere.

I wondered about that, because it seems like the kind of thing that
would have undefined behaviour, but I looked at the C standard, and on
my reading it actually doesn't.  The relevant wording is

#   An object whose identifier is declared with no linkage and without the
#   storage-class specifier "static" has /automatic storage duration/.
#   [...] storage is guaranteed to be reserved for a new instance of
#   the object on each entry into the block with which it is associated;
#   the initial value of the object is indeterminate.

To have an indeterminate value does not amount to undefined behaviour.
When we have no initialising clause at all, clearly the indeterminate
value is not a problem if we don't rely on the value; that is how the code
is currently correct.  An "x = x" initialiser amounts to an assignment
using that initial indeterminate value.  Crucially, there's nothing saying
that using an indeterminate value per se invokes undefined behaviour.
My reading is that an indeterminate value is some actual value, though
we don't know which value it is, and that copying it by assignment
or initialisation just copies whatever value it is without trouble.
Thus "x = x" is truly a no-op.

So I think we'd be fine to adopt the "x = x" idiom without any
conditionality.  Of course, the idiom might elicit *more* warnings
from compilers other than gcc, and that could be a reason to use it
conditionally even if correctness isn't on the line.  One also might
want to hide it behind a macro even if used unconditionally, on the
grounds that the macro name makes clearer what's going on.

-zefram