[tz] proposed changes for Win32 and a improved mktime() algorithm
Clive D.W. Feather
clive at davros.org
Thu May 18 20:24:31 UTC 2017
>> 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
> # the initial value of the object is indeterminate.
> To have an indeterminate value does not amount to undefined behaviour.
But an indeterminate value doesn't have to be a valid value; it can be a
trap representation [C99 3.17.2].
> 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.
Which could be a trap representation.
> Crucially, there's nothing saying
> that using an indeterminate value per se invokes undefined behaviour.
Yes, there is. Reading, let alone writing, a trap representation is undefined
behaviour [C99 188.8.131.52 paragraph 5].
> 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.
That, I'm afraid, is wrong [C99 footnote 41].
(I am the person who wrote 6.2.6.)
Clive D.W. Feather | If you lie to the compiler,
Email: clive at davros.org | it will get its revenge.
Web: http://www.davros.org | - Henry Spencer
Mobile: +44 7973 377646
More information about the tz