Skip to content

libuuid: Add uuid_time64 for 64bit time_t on 32bit#2610

Merged
karelzak merged 1 commit intoutil-linux:masterfrom
thkukuk:uuid-time64_t
Dec 11, 2023
Merged

libuuid: Add uuid_time64 for 64bit time_t on 32bit#2610
karelzak merged 1 commit intoutil-linux:masterfrom
thkukuk:uuid-time64_t

Conversation

@thkukuk
Copy link
Contributor

@thkukuk thkukuk commented Nov 30, 2023

There is one big problem where I don't know how to solve best: it is not expected that uuid_time() can fail. But with an uuid created e.g. 2040, it has to fail. The current "error handling" by does not really work, any ideas how this could be done better?
My current proposal would be, set ret_val to NULL, set errno and return -1.

Else the behavior depends on with which flags which parts where compiled:

Old 32bit binary using libuuid with time64_t: identical output as with libuuid.so.1.3.0 for UUIDs created before 2038. With UUIDs created after 2038, error handling is missing.

New 32bit binary with time64_t linked against time64_t compiled libuuid: everything works correct.

New 32bit binary with time64_t linked against time64_t compiled libuuid, but running with a new libuuid compiled without time64_t:
/lib/libuuid.so.1: version `UUID_2.40' not found (required by ./uuid_time-time64_t)

@thkukuk
Copy link
Contributor Author

thkukuk commented Nov 30, 2023

According to the failed tests distributions like openwrt seems to build util-linux already with time64_t on 32bit architectures. My patch will break binary compatibility for uuid_time() for them, but since they are already incompatible, I don't think we need to care.

@t-8ch
Copy link
Member

t-8ch commented Nov 30, 2023

OpenWRT uses musl libc which always uses 64bit time since version 1.2 from 2020.

@thkukuk thkukuk marked this pull request as ready for review December 1, 2023 09:56
@thkukuk
Copy link
Contributor Author

thkukuk commented Dec 1, 2023

For me, this one works now and should unblock PR#2168
I'm only not really happy about the situation, where an old 32bit binary calls uuid_time() with an uuid generated post 2038. But Ok, this old 32bit binary will most likely not even start anyways...

@thkukuk
Copy link
Contributor Author

thkukuk commented Dec 7, 2023

No idea why the lslocks tests are always randomly failing, the binary does not use libuuid at all

@karelzak is this PR now good for you?

@karelzak
Copy link
Collaborator

karelzak commented Dec 7, 2023

Please, ignore the lslocks test.

@karelzak
Copy link
Collaborator

karelzak commented Dec 7, 2023

Yes, it seems good to me.

How do you test it? Maybe readelf -a /lib64/libuuid.so | grep uuid_time
Can you share any autotools setting to compile against 32-bit glibc (or so)?

@t-8ch any objection?

Maybe we can add some note about 64-bit time to libuuid/man/uuid_time.3.adoc

@thkukuk
Copy link
Contributor Author

thkukuk commented Dec 7, 2023

How do you test it? Maybe readelf -a /lib64/libuuid.so | grep uuid_time Can you share any autotools setting to compile against 32-bit glibc (or so)?

I created several UUIDs with times before and after 2038 and wrote a small C program using uuid_time to get the time out of the UUIDs and verified, it's correct. This program got compiled in several 32bit flavors with 32bit and 64bit time_t and linked against old and new libuuid. Afterwards I run them all with the old and new library and compared the results. But I have no idea how to put this into a testsuite, as you need the "old" 32bit binaries.

For autotools settings, there is PR#2168, else CFLAGS="-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 ..." ./configure ...

@karelzak karelzak merged commit 35fe980 into util-linux:master Dec 11, 2023
@thkukuk thkukuk deleted the uuid-time64_t branch December 11, 2023 10:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants