Re: [PATCH] time: Avoid alignment gaps in __tzfile_read

[Florian Weimer <fweimer at redhat dot com>]

* Paul Eggert:

> Florian Weimer wrote:
>> This is a long-term allocation, and
>> the reading of the file happens only once per allocation, so I do think
>> that the additional __fread_unlocked call is not a problem from a
>> performance perspective.
>
> The upstream code uses a single 'read' call, bypassing stdio
> entirely. It doesn't even stat the file; all it does is 'access' (if a
> relative filename, for security reasons), 'open', 'read', 'close'. I
> wonder why glibc went to stdio for this? Seems overkill. In practice,
> I'd think going back to syscalls would gain more performance than any
> of the stuff we've talked about so far.

It's not about performance, it's about simplifying the code in
preparation of eliminating most of the locking.

> Anyway - if we're moving things around, how about putting 'leaps'
> before 'transitions' instead of after? This will eliminate alignment
> gaps just as well in practice, and it will allow us to do one fread
> instead of two.

This is not possible because struct leap has alignment 4 on i386, while
the transitions array has alignment 8.  Sorry.

+     The order of the suballocations is important for alignment
+     purposes.  __time64_t outside a struct may require more alignment
+     then inside a struct on some architectures, so it must come
+     first. */

> PS. While you're in the neighborhood, the leap second correction field
> (struct leap.change) can be 'int' instead of 'long int', as the TZif
> format allows only 32 bits of (signed) correction.

I know, but I'm pondering whether we should leap second support
altogether because it leads to non-conformance with POSIX.

Thanks,
Florian