Hi Martin, On Wed, Feb 21, 2024 at 06:56:09AM +0000, Martin Kepplinger wrote: > in general, tslib only ever uses time_t differences, so apart from one > glitch when wrapping around, the library will continue to work after > 2038 as-is.
Sorry, but that's immaterial: per <https://adrien.dcln.fr/misc/armhf-time_t/2024-02-22T21%3A03%3A00/compat_reports/libts-dev/lfs_to_time_t/compat_report.html>, the ts_read() family of functions take a pointer to a struct that contains a struct timeval, which means that sizes and offsets of elements in that struct will be interpreted incorrectly across the ABI horizon. This is an ABI break. It's the last element of struct ts_sample so offsets are not an issue, but depending on the endianness of the architecture, a caller that doesn't know you've moved to 64-bit time_t will be reading the wrong word; and anything caller-side that happens to allocate arrays of ts_sample will get the wrong size of the element. (I'm assuming by the description of the functions in the header that ts_sample is always allocated by the library and not by the caller.) But for ts_sample_mt it's even worse, the tv is in the middle of the struct and throws everything off. > I'll look at what `__TIMESIZE` currently is on 32bit archs. But given > the low-impact this has for tslib functionality-wise, I'd rather find > the correct change (any help appreciated), and increment LT_CURRENT. > So: where do I start in order to comply with your scripts? do I simply > add `D__USE_TIME_BITS64` to CPPFLAGS? Once gcc and dpkg have been uploaded to unstable, we will be batch NMUing these patches to unstable as well. There should be no need for you to manually adjust CPPFLAGS in your package; simply incorporating the NMU changes will be sufficient. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
