Control: tags -1 -pending Control: close -1 On Sat, 03 Feb 2024 11:31:57 -0800 David Woodhouse <dw...@infradead.org> wrote: > This looks like overkill to me, for openconnect. > > There's precisely one function exported from libopenconnect which uses > time_t, and I suspect there aren't any *users* of that function in the > distribution anyway (neither openconnect(8) nor NetworkManager- > openconnect use it). So although it's not best practice, we could > actually get away with just *dropping* that function, and adding a new > function which returns either an explicit 64-bit value or a timespec or > something. > > Alternatively... on how many of our 64-bit architectures can we just > return the high 32 bits of the 64-bit time_t in a register that we > call-clobbered anyway — so callers who expect a 64-bit time_t get to > see it all, and callers who expect a 32-bit time_t just don't notice? > The contents of the *low* 32 bits are the same either way, right? > > It definitely doesn't seem like we need to switch to a new soname ... > except *are* you switching the soname? Or just the package name? It > looks like the symbol versions are remaining the *same*...? How does > that work?
I agree, this is completely pointless. Even if the function was actually used, it's armv7 for crying out loud, nobody is going to use today's TLS protocols in 2038 on an armv7 box, they barely last a couple of years before vendors do incompatible changes. I'd much rather drop the armv7 build entirely if push came to shove. -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
