Skip to content

Conversation

@snogge
Copy link
Contributor

@snogge snogge commented Aug 14, 2025

Description

Use the input_event_sec and input_event_usec members (macros in C) on all platforms, no matter whether time_t is 32 or 64 bits.
This means the same members are available in the struct no matter whether it is a 32 or 64 bit platform or the linux_time_bits64 config is set.

This is a breaking change.

Sources

https://github.com/torvalds/linux/blob/0cc53520e68bea7fb80fdc6bdf8d226d1b6a98d9/include/uapi/linux/input.h#L28

Checklist

  • Relevant tests in libc-test/semver have been updated
  • No placeholder or unstable values like *LAST or *MAX are
    included (see #3131)
  • Tested locally (cd libc-test && cargo test --target mytarget);
    especially relevant for platforms that may not be checked in CI

This is a breaking change and should not be backported to the 0.2 branch.

This means the same members are available in the struct no matter
whether it is a 32 or 64 bit platform or the linux_time_bits64 config
is set.
Copy link
Contributor

@tgross35 tgross35 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm sorry this has taken me forever to come to consensus on, but I do now think this is the right approach. I have a couple of non-technical requests, the code changes LGTM.

Comment on lines -335 to 338
// FIXME(1.0): Change to the commented variant, see https://github.com/rust-lang/libc/pull/4148#discussion_r1857511742
#[cfg(any(target_pointer_width = "64", not(linux_time_bits64)))]
pub time: crate::timeval,
// #[cfg(any(target_pointer_width = "64", not(linux_time_bits64)))]
// pub input_event_sec: time_t,
// #[cfg(any(target_pointer_width = "64", not(linux_time_bits64)))]
// pub input_event_usec: suseconds_t,
// #[cfg(target_arch = "sparc64")]
// _pad1: c_int,
pub input_event_sec: crate::time_t,
#[cfg(all(target_pointer_width = "32", linux_time_bits64))]
pub input_event_sec: c_ulong,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add a comment that these are actually combined as timeval?

Comment on lines +345 to +346
#[cfg(target_arch = "sparc64")]
_pad1: c_int,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to backport this part of the change. It is technically breaking but our definition is incorrect without it, and sparc64 isn't all that popular of a target. Would you be able to split this to a separate commit?

Padding fields should also get wrapped in Padding<...> now

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm - actually, I think this change may not be correct on its own. Looks like the __usec/input_event_usec field would also need to be changed from a long to an int https://github.com/torvalds/linux/blob/3f9f0252130e7dd60d41be0802bf58f6471c691d/include/uapi/linux/input.h#L35C6-L42.

We should probably do that change still to make sure users don't expect the upper half of that field to work, just annoying that sparc has a special-cased suseconds_t in the first place.

(context: torvalds/linux@2e74694)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nevermind, I see now that the field is of type suseconds_t. Sorry for the confusion; please disregard everything in this thread except for the Padding<...> bit.

@rustbot
Copy link
Collaborator

rustbot commented Dec 3, 2025

Reminder, once the PR becomes ready for a review, use @rustbot ready.

@tgross35 tgross35 mentioned this pull request Dec 3, 2025
3 tasks
@snogge
Copy link
Contributor Author

snogge commented Dec 4, 2025

I've seen your comments and hope to get around to this next week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants