If the value is 200112L, then the implementation of the monotonic clock is as specified in that version of the standard (where it was optional). If the value is 200809L, then the implementation of the monotonic clock is as specified in that version (where it was optional). And so on ...
The introductory paragraph explains all this: "If (the value) is defined with a value greater than zero, the option shall always be supported when the application is executed." So, if you care _how_ the clock behaves (assuming it changed from version to version, which it didn't), test for a specific version : #if _POSIX_MONOTONIC_CLOCK == 200809L But if all you care about is "can I rely on there being a monotonic clock", then your code should read: #if _POSIX_MONOTONIC_CLOCK > 0 or, assuming we didn't make a breaking change, is the clock at least as it was in Issue 7: #if _POSIX_MONOTONIC_CLOCK >= 200809L -- Nick On Thu, Dec 3, 2020 at 10:26 AM Robert Elz via austin-group-l at The Open Group <austin-group-l@opengroup.org> wrote: > Date: Thu, 3 Dec 2020 18:11:51 +0000 (UTC) > From: shwaresyst <shwares...@aol.com> > Message-ID: <684426419.4103424.1607019111...@mail.yahoo.com> > > | The 20yymmL shall be replaced with the value specific to Issue 8 when > that > | is finalized, not that an implementation may choose an arbitrary value > | after 2000. It's a placeholder to indicate this for the bug report > only. > > Yes, that's what I assumed, and said in my message: > > austin-group-l@opengroup.org (that was me...) said: > | (I read the latter as meaning that it will become the actual date of > the > | standard, not yet known). > > Back to quote from shwares...@aol.com: > > | The other 200809L values all get a blanket change eventually too, > > If that is the standard procedure, then sorry, but that's insane. > > | consistent with the changes from Issue 6 to Issue 7. > > If the reason that NetBSD has 200112L and the standard (Issue 7) now > requries 200809L, is solely that (ie: there were no other changes to > the CLOCK_MONOTONIC specification between whichever version 200112L > identifies, and Issue 7) then that's a defect in the standard, and > should be fixed. > > Making arbitrary changes that render all implementations non-conforming > and break applications that relied upon the earlier specification is > totally bizarre behaviour. > > kre > >
