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:
>>> 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.
Well, or we could use this patch.
>> 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,
With the old allocation order:
0000000000000000 0000000000000d4c T __tzfile_read
With the new allocation order:
0000000000000000 0000000000000cd8 T __tzfile_read
So it's not just the allocations that are more compact, the code is as
>> 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
> 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/
It's not possible to do this on Linux because if the kernel clock does
not run on an UTC clock, many programs will not report the correct time.
Even if all these applications were magically fixed to use the glibc
functions (which includes gmtime_r with its locking overhead, something
many programs avoid for performance reasons), then the current code is
still broken because it does not reload the time zone data when new leap
second information is added to it.
Anyway, this is a separate discussion.