Page MenuHomeFreeBSD

Add timespecvalid macro and use it.
ClosedPublic

Authored by dchagin on Apr 8 2022, 7:45 PM.
Tags
None
Referenced Files
Unknown Object (File)
May 12 2024, 12:40 AM
Unknown Object (File)
May 10 2024, 11:36 PM
Unknown Object (File)
May 10 2024, 11:36 PM
Unknown Object (File)
May 10 2024, 4:44 AM
Unknown Object (File)
May 10 2024, 4:43 AM
Unknown Object (File)
May 9 2024, 9:53 PM
Unknown Object (File)
Feb 19 2024, 12:27 AM
Unknown Object (File)
Dec 20 2023, 12:19 AM
Subscribers

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

I agree with doing the refactor, I just worry about the name. A timespec can legitimately have a valid tv_sec that is < 0 if it is representing a wall-time before the epoch (so a negative time_t value). OTOH, these checks here are for timespecs that represent an interval relative rather than an absolute wall time and so requiring tv_sec to be non-negative makes sense. I worry that timespecvalid is too generic of a name as it would fail on valid wall-time structures and that the name would tempt people to use it when they shouldn't. (And I wonder in fact if the checks in compat/linux are too strict, e.g. if it would both an attempt to set a time on a file via utimes(2) or the like to a time before Jan 1, 1970.)

I'd recommend 'valid_interval' instead of timespecvalid or something similar. All instances in this patch are for intervals (relative time) rather than an absolute time (which is just a relative time to 1970, but semantically different and the term 'abs time' or 'absolute time' is used to refer to this sort of time).

Otherwise it looks good.

Yeah, agreed, renamed to timespecvalid_interval. Thanks!

compat/linux utimes does not uses this check and allows negative sec values.

This revision is now accepted and ready to land.Apr 14 2022, 10:40 PM
This revision was automatically updated to reflect the committed changes.