[tz] Minor (unimportant really) technical UB bug in strftime() ?

[John Marvin]

I'm not sure what the standard says about struct copies, but I know that 
most compilers do struct copies by just copying the raw bytes for the 
size of the structure, and don't copy each field using the type of the 
field. so replacing the struct copy with a memcpy would not make a 
functional difference.

John

On 11/9/2022 12:25 PM, Tom Lane via tz wrote:
> Paul Eggert via tz <tz at iana.org> writes:
>> For example, see the following behavior observed on Fedora 36 x86-64.
>> Although the C standard says this program is OK, Valgrind says it's not.
>>     int main (void)
>>     {
>>       int y;
>>       memcpy (&x, &y, sizeof x);
>>       return x ? 27 : 49;
>>     }
> I think you are misinterpreting what Valgrind does, too.  It does not
> complain about that memcpy.  What it does during the memcpy is to copy
> its defined-ness status for the bytes of y to the bytes of x.  Then
> it complains when you use the now-known-undefined value of x in the
> return statement.  So in the case in strftime(), Valgrind would only
> complain if mktime() actually tried to use any fields that had not
> been initialized by the caller of strftime().  Which is just what
> one would want.
>
> So AFAICS, both Valgrind and the letter of the C standard agree that
> using memcpy to copy the tm struct will be fine.  With the additional
> datum that nobody has complained about this code in decades, I can't
> see an argument for writing longer and more fragile code as a
> substitute for a full-struct copy.
>
> 			regards, tom lane