Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TimeVal's members are 64 bit, per the unix package #100

Merged
merged 1 commit into from
Apr 16, 2024

Conversation

geekosaur
Copy link
Contributor

@geekosaur geekosaur commented Apr 16, 2024

Fixes #99.
Eventually we should update waitForEvent's type signature to match.

@geekosaur geekosaur merged commit 1ead969 into xmonad:master Apr 16, 2024
18 checks passed
@geekosaur
Copy link
Contributor Author

Do we want to make a Hackage update for this?

@slotThe
Copy link
Member

slotThe commented Apr 20, 2024

Do we want to make a Hackage update for this?

Sure, why not

@liskin
Copy link
Member

liskin commented Apr 27, 2024

I wonder why this ever worked… did we just get extremely lucky that the bytes happened to be zeroed somehow?

(Anyway, the new code will break again somewhat soon because Debian is transitioning to 64-bit time_t on 32-bit platforms but CLong is 32-bit. Wouldn't be surprised if nobody complains though because who runs xmonad on a 32-bit Debian these days?)

@geekosaur
Copy link
Contributor Author

xmonad doesn't use this API, and the OP said it took (iirc) several hundred calls before the upper bits went nonzero.

@geekosaur
Copy link
Contributor Author

Oh, also, the code just replicates unix's CTimeVal, so there will be bigger breakage afoot in the Haskell community when that happens. (cc @Bodigrim)

@Bodigrim
Copy link

I'm out of context, but if you raise an issue at https://github.com/haskell/unix/issues it would be most appreciated.

@liskin
Copy link
Member

liskin commented Apr 27, 2024

I'm out of context, but if you raise an issue at https://github.com/haskell/unix/issues it would be most appreciated.

haskell/unix#252 (comment)

It also looks like the Debian people are submitting patches upstream (and backporting them in Debian) throughout the t64 migration so it's quite possible they'd take care of it eventually anyway.

@liskin
Copy link
Member

liskin commented Apr 27, 2024

(Anyway, the new code will break again somewhat soon because Debian is transitioning to 64-bit time_t on 32-bit platforms but CLong is 32-bit. Wouldn't be surprised if nobody complains though because who runs xmonad on a 32-bit Debian these days?)

We'll also need to use CApiFFI for select if we want to be Y2038-safe on i386. Which we maybe don't care about because by then maybe the whole Wayland thing will be concluded, and there won't be any 32-bit xmonad users anyway…

@liskin
Copy link
Member

liskin commented Apr 30, 2024

(Anyway, the new code will break again somewhat soon because Debian is transitioning to 64-bit time_t on 32-bit platforms but CLong is 32-bit. Wouldn't be surprised if nobody complains though because who runs xmonad on a 32-bit Debian these days?)

We'll also need to use CApiFFI for select if we want to be Y2038-safe on i386. Which we maybe don't care about because by then maybe the whole Wayland thing will be concluded, and there won't be any 32-bit xmonad users anyway…

Actually, the impact is even more limited. Debian's i386 port is staying with 32-bit time_t because its main usecase is compatibility with old i386 binaries, and breaking ABI would defeat that purporse. So it's only the armel, armhf, and a few non-release architectures (whatever that means in Debian terminology) that are actually affected by the ABI change.

So… it essentially only affects people with the Nokia N900 and similar old hardware… :-D

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.

waitForEvent dpy 0 eventually waits indefinitely
4 participants