[PATCH] time: Avoid alignment gaps in __tzfile_read

Paul Eggert eggert@cs.ucla.edu
Sun Feb 3 19:32:00 GMT 2019


Florian Weimer wrote:

>> 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.

If that's the issue, we can easily change struct leap to have an alignment of 8 
on x86-64 by using an alignment directive, or (less good) change the transitions 
array to have an alignment of 4 by packaging each transition value inside a struct.

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

I guess I'm not seeing the point. The code isn't that much simpler and it is 
surely a bit fatter and slower, and I don't see how the simplification would 
make it easier to eliminate most locking. Perhaps it'll become more obvious in 
later patches....

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

Oh my, that would be a bigger deal. Strictly speaking glibc currently conforms 
to POSIX in this respect, so what you're pondering is removing an extension to 
POSIX rather than fixing a conformance issue. Has anybody else ever done that; 
that is, has any other C library supported tzdb-style leap seconds and then 
removed the support?

PS. It would be ironic for glibc to remove leap second support at about the same 
time that Microsoft Windows finally added support. See:

Cuomo D. Top 10 Networking Features in Windows Server 2019: #10 Accurate Network 
Time. [Microsoft] Networking Blog. 2018-07-18. 
https://blogs.technet.microsoft.com/networking/2018/07/18/top10-ws2019-hatime/



More information about the Libc-alpha mailing list