On 05/04/2025 19:02, Philip Rowlands wrote:
I was interested to see that the code makes uses of strtod, and how this
interacts with the minute / hour / day suffix.
$ strace -e trace=clock_nanosleep sleep 3
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=3, tv_nsec=0},
$ strace -e trace=clock_nanosleep sleep 0xas
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=10, tv_nsec=0},
$ strace -e trace=clock_nanosleep sleep 0xam
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=600, tv_nsec=0},
$ strace -e trace=clock_nanosleep sleep 0xad
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=173, tv_nsec=0},
Here 0xad is interpreted as 173 seconds, not 10 days.
It's a corner case, but should sleep(1) support or tolerate hex input, and if so, how
should it handle the "d" suffix? FWIW I'd just vote to return an error for hex
intervals.
Good point :)
Given FreeBSD and ksh sleep implementations also behave like GNU,
we should probably just document the edge case that
(day) suffixes are best avoided with hex inputs.
~$ ksh
$ type sleep
sleep is a shell builtin
$ time sleep 0x10d
real 4m29.00s
cheers,
Pádraig