This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] time: Avoid alignment gaps in __tzfile_read
* 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.