Re: Unification of common date/time macros

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 16 Sep 2014 01:37:11 +0200
    From:        "Kamil Rytarowski" <n54%gmx.com@localhost>
    Message-ID:  <trinity-b05998cc-53a3-45bb-b083-35267de76e00-1410824231175@3capp-mailcom-bs14>


  | 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.)

Changing any of the others to long would change the semantics of existing
code that uses them (as would changing away from long in the kernels of
those architectures where the symbols are currently defined that way - though
that's less of a problem, internal kernel APIs can be changed when needed,
fixing the breakage is a reasonable (and bounded) amount of work.)

I have no problem with unifying the things in one common header file that
can be used by everyone, but I cannot think of a single rational reason why
DAYSPERWEEK (ie: 7) needs to be long to be useful (or the others that are
currently defined as int.)

If you really believe that some code would benefit from having them all be
long, then do it (in the new file) like ...

#ifndef	_CAL_CONST_TYPE
#define	_CAL_CONST_TYPE  int
#endif

typedef	_CAL_CONST_TYPE   __cal_c_t;

#define  DAYSPERWEEK	 ((__cal_c_t) 7)
(etc)

Then any code that needs the constants to be long for whatever reason
can just

#define _CAL_CONST_TYPE long

before including this new file or anything that includes it, so to be
safe it would be done before any includes, or on the cc command line.

Such code would really need to understand the implications however
(and if someone needs them to be long long, or even float or double,
they can have what they want too.)

[And apologies if I haven't used leading _'s the way they should be,
adjust that however is required to keep it all standards compliant.]

kre