I agree with Robert on this. Bumping the value of these macros when there's no change to the specified behavior of the relevant functionality provides no benefit and is actively harmful to code being forward portable.
Yes, this makes the text of the specification for these more complex, while bumping them on each version would relieve those of us involved in the standard from the burden of thinking through when the values should change...but if _we_ can't tell then how can the much-less-involved application authors tell what the values mean! Note that applications can always check _POSIX_VERSION if they want to know the "newest supported version", and could take the maximum of those if they wanted the effect of the "bump every time" behavior. Philip Guenther On Thu, Dec 3, 2020 at 11:35 AM Robert Elz via austin-group-l at The Open Group <austin-group-l@opengroup.org> wrote: > Date: Thu, 3 Dec 2020 10:53:43 -0800 > From: Nick Stoughton <nickstough...@gmail.com> > Message-ID: <CAA3V+jTN1X0TQYKqf=v=xT2aEUeXsM90sodc8yDACa=_ > jxu...@mail.gmail.com> > > | 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 ... > > Yes, I understood that. > > | 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." > > Yes, and that is fine. > > | 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 > > Yes, that's good. But that will then break if the code encounters > an implementation of Posix 202x (ie: Issue 8) or later - even though > there have been no changes which actually break anything. > > | 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 > > but that is dangerous, as that means that the code will be used for > any future specification of MONOTONIC_CLOCK regardless of what changes > this group might decide to make. > > If I read the standard, and implement it, and some application developer > reads the standard the same way, and uses my implementation, and does it > with a test like that one, and then it later turns out the the > specification > wasn't as clear as it ought to have been, and neither I, nor the > application > developer read it as intended, and a later version of the standard > clarifies > the intent, and I update my implementation to conform, updating the > feature test macro at the same time, the application code will never be > aware that anything is wrong, but will no longer get the behaviour they > were expecting, and had obtained before. > > If their test had used the == form that would not be a problem, they'd > either fall back on some alternate implementation method, or fail to > compile (or run, if using sysconf() rather than <unistd.h>) allowing > the issue to be detected and corrected. > > That is, applications should never be using the >0 type tests for these > things, as that would be assuming the the standard never can change in a > seemingly incompatible way, which is absurd to attempt to promise, and > not born out by history (though it might currently be true of > CLOCK_MONOTONIC). > > | 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 > > That's just as dangerous, for the same reason - it just specifies a > different > base version to require. > > But your message didn't address the more important issue - that is why > these things need to alter when the specification hasn't altered (changing > from optional to required is not an alteration of the spec - or not one > that affects applications, who are the consumers of these values). > > What's the point of changing them (when there has been no underlying > change) ? > > kre > >
