Control: severity -1 important On Sat, 13 Jan 2024 at 19:32:58 +0000, Simon McVittie wrote: > On Sat, 13 Jan 2024 at 16:21:46 +0000, Simon McVittie wrote: > > On Sat, 13 Jan 2024 at 15:21:02 +0000, Simon McVittie wrote: > > > I recently uploaded a snapshot of GLib 2.79.x to experimental (in > > > preparation for NEW processing) and it failed tests on s390x and on > > > the 64-bit, big-endian ports ppc64 and sparc64. I suspect this means > > > it's a general problem with 64-bit BE, rather than specifically s390x. > > > > git bisect says commit df4aea76 "gdatetime: Add support for %E modifier > > to g_date_time_format()" is the first bad commit, which would be consistent > > with it being... > > > > > instead > > > of segfaulting, the test failed with an assertion error involving dates > > > with > > > a Japanese era marker: > > > > ... something to do with Japanese and Thai eras, and the %E modifier. > > I can't see anything in the relevant commit[1] that looks like it would be > affected by endianness. Could there be an endianness problem in one of the > glibc APIs that it's calling into, or something like that?
I have successfully worked around this by disabling support for era-based dates with the %E modifier (used in Japan and Thailand) on big-endian 64-bit, which reduces the severity of this bug to non-RC. It looks as though: - glibc documents nl_langinfo(ERA) as returning a semicolon-delimited list of eras - but in fact it returns a NUL-delimited, double-NUL-terminated list of eras, such that parsing the list cannot be done without risking a read overrun, unless you either assume that the undocumented double-NUL-termination will be present or use the undocumented nl_langinfo(_NL_TIME_ERA_NUM_ENTRIES). GLib currently does the latter. - GLib has, at least for now, prioritized its own usability for Japanese and Thai users higher than the design principle that it should not rely on undocumented APIs - this is OK on 32-bit and on little-endian, but glibc's nl_langinfo(_NL_TIME_ERA_NUM_ENTRIES) returns what appears to be a wrong result on 64-bit big-endian architectures Discussion in GLib: https://gitlab.gnome.org/GNOME/glib/-/issues/3225 Workaround in GLib: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3820 Related glibc bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31030 If there is a safe way to get this information from glibc, then GLib should use that, but I don't know what that safe way would be. smcv
