Keith Marshall
keith****@users*****
Mon Jul 30 11:11:42 JST 2018
On 29/07/18 20:03, Eli Zaretskii wrote: > It seems Posix requires CLOCK_REALTIME (and probably also > CLOCK_MONOTONIC) to be macros. See the discussion starting at > > 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. 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). Now, returning to Eli's statement of the issue: > But MinGW runtime 5.1.0 headers define those two as variable names. I contend that this is sufficient to comply with the strict stipulations of the 2018 edition of POSIX.1-2008; the two constants in question *are* symbolic, (insofar as they are symbolically named), and their values do represent the correct clockid_t data type. (Admittedly, I did neglect to assert their constancy property, in their respective declarations, but they are implemented as constant pointers to the requisite instances of the associated data structures). > This issue currently prevents using MinGW clock_gettime instead of > gettimeofday, since the latter is now being flagged as deprecated when > MinGW runtime 5.1.0 headers are used. Yes, gettimeofday() is marked as obsolescent in POSIX.1-2008, and POSIX forbids use of obsolescent APIs; hence the deprecation warning, unless you explicitly define _POSIX_C_SOURCE with a value less than 200809L, (or preferably, you define _XOPEN_SOURCE with a value of 600 or less). 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? -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -------------- next part -------------- A non-text attachment was scrubbed... Name: time.h Type: text/x-chdr Size: 21460 bytes Desc: not available Url : https://lists.osdn.me/mailman/archives/mingw-users/attachments/20180730/07b30113/attachment-0001.h -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature Url : https://lists.osdn.me/mailman/archives/mingw-users/attachments/20180730/07b30113/attachment-0001.pgp
Fork