On Mon, 22 Sep 2014, Robert Elz wrote:
| My proposition is [...]
|
| #define SECSPERMIN 60L
| #define MINSPERHOUR 60L
| #define HOURSPERDAY 24L
| #define DAYSPERWEEK 7L
| #define DAYSPERNYEAR 365L
| #define DAYSPERLYEAR 366L
| #define SECSPERHOUR (SECSPERMIN * MINSPERHOUR)
| #define SECSPERDAY (SECSPERHOUR * HOURSPERDAY)
| #define MONSPERYEAR 12L
| #define EPOCH_YEAR 1970L
Why are they all to be long ? The only one that has even the
slightest potential for that need (and which is currently
defined as long for the userspace definitions) is SECSPERDAY,
and that's only to cope with the possibility that int is 16 bits
(which I don't think NetBSD supports at all, since there is no
pdp11 port - but is kept that way for API consistency.)
kre's analysis is correct. I'd just define them all as plain
numbers, without any "L", "U", or "UL" suffix. I'd probably
also use 3600 and 86400 for SECSPERHOUR and SECSPERDAY, to avoid
surprises in the arithmetic.
For an example of an unwanted surprise, consider (SECSPERHOUR
* HOURSPERDAY) or ((60 * 60) * 24) on a machine with 16-bit
ints: the desired result of 86400 is too large to represent in 16
bits, which causes undefined behaviour. NetBSD doesn't support
any machines with 16-bit int, but this is the sort of code where
it's easy to accommodate such machines, so we might as well do it.
--apb (Alan Barrett)
