Eli Zaretskii
eliz****@gnu*****
Tue Jul 31 00:13:57 JST 2018
> From: Keith Marshall <keith****@users*****> > Date: Mon, 30 Jul 2018 03:11:42 +0100 > > > https://lists.gnu.org/archive/html/bug-gnulib/2018-07/msg00116.html > > In which Paul Eggert (erroneously) states: > > Yes, the POSIX spec for <time.h> requires CLOCK_REALTIME to be a > > symbolic constant, and it says that a symbolic constant must be a > > macro that expands to a compile-time constant expression with an > > integer type (it need not be usable in #if). > > With all respect due to Eggert, for the most part, POSIX says no such > thing. Let's break it down: > > > Yes, the POSIX spec for <time.h> requires CLOCK_REALTIME to be a > > symbolic constant, ... > > Indeed, to this extent, (and not much further), Eggert is correct. > > > ... and it says that a symbolic constant must be a macro ... > > No, it doesn't; other forms of symbolic constant are permitted. What > POSIX actually says, is that *individually* symbolic constants *may* be > required to be defined as macros; the <time.h> specification stipulates > no such requirement for either CLOCK_REALTIME, or CLOCK_MONOTONIC. Well, at least this page: http://pubs.opengroup.org/onlinepubs/9699919799/ says (under "Symbolic Constant"): 3.380 Symbolic Constant An object-like macro defined with a constant value. Unless stated otherwise, the following shall apply to every symbolic constant: . It expands to a compile-time constant expression with an integer type. . It may be defined as another type of constant-e.g., an enumeration constant-as well as being a macro. . It need not be usable in #if preprocessing directives. > In the general case, when a symbolic constant is not defined as a macro, > POSIX *suggests*, but does *not require*, that a trivial > self-referencing macro alias may be provided. > > > ... that expands to a compile-time constant expression ... > > On the contrary, POSIX says the exact opposite: there is no requirement > that it be a "constant compile-time expression"; indeed it is explicitly > stated that "macros are not required to be usable in #if, or even to > expand to constant expressions, unless explicitly stated", (and there is > no such explicit stipulation, in the cases of either CLOCK_REALTIME, or > CLOCK_MONOTONIC). > > > ... with an integer type ... > > Here, Eggert is quite wrong. POSIX says "The description of the symbol > can override individual requirements for symbolic constants; e.g., to > specify a non-integer type, or to add a requirement that the symbol is > usable in #if preprocessor directives". In the particular cases of > CLOCK_REALTIME, and CLOCK_MONOTONIC, the description in the <time.h> > specification is explicit: "The values shall have a type that is > assignment-compatible with clockid_t"; in the MinGW.org implementation, > clockid_t is a pointer to an opaque data structure, so it is entirely > appropriate the these symbolic constants are so defined; (there is no > specified POSIX requirement that these constants be usable with #if). > > > ... (it need not be usable in #if). > > This final clause of Eggert's statement is correct, (not that it has any > impact on the issue at hand, since it is #ifdef processing, rather than > #if, which would have a mitigating effect). I think you are reading different versions of Posix. Anyway, I'm not an expert on this, I just want this to work ;-) > I suspect that the solution for clock_gettime() is trivial. Although > POSIX.1-2008 may not strictly require them, it does allow, and it would > certainly be prudent to add, self-referencing macro aliases for the two > symbolic constants. > > Does the attached replacement for $MINGW_ROOT/include/time.h provide a > satisfactory work-around? It will most definitely solve the problem, because all that is needed is for CLOCK_REALTIME to be a macro which can be tested by "#if defined". Thanks.