[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