Path: csiph.com!weretis.net!feeder8.news.weretis.net!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Pete Forman Newsgroups: comp.std.c Subject: Re: C23: asctime is obsolescent Date: Mon, 21 Aug 2023 17:42:44 +0100 Organization: A noiseless patient Spider Lines: 125 Message-ID: References: <875yf5ksn9.fsf@nosuchdomain.example.com> <861qocrk5b.fsf@linuxsc.com> <867cx5gpgo.fsf@linuxsc.com> <874js8j18h.fsf@nosuchdomain.example.com> <86h6pyzewi.fsf@linuxsc.com> <87351is0i5.fsf@nosuchdomain.example.com> <865y5i8tqc.fsf@linuxsc.com> <87v8dimrmi.fsf@nosuchdomain.example.com> <87ttsxjujd.fsf@nosuchdomain.example.com> <0z-dnUFPU_BLNkP5nZ2dnZeNn_WdnZ2d@giganews.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Info: dont-email.me; posting-host="ea8927bc2ab431ebe1a4b30f330d88bc"; logging-data="2089786"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/JzDcxXYaG4AhUg2GZlDAv" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (windows-nt) Cancel-Lock: sha1:ilZqlN8++hszzO1ER7vdw9m1fBQ= sha1:fMjbgxy0yCdKlqNzDfwo62hDSS4= Xref: csiph.com comp.std.c:6555 Jakob Bohm writes: > On 2023-08-17 22:14, Keith Thompson wrote: >> Jakob Bohm writes: >>> On 2023-08-14 01:47, Keith Thompson wrote: >>>> ... >>>> I consider the proposed "8601" in the macro name to be cruft. I don't >>>> want to add more cruft to my code to avoid it. If it were defined as >>>> __ISO_8601_DATE__, I'd just use that. >>>> __DATE__ would be perfect if it weren't already taken. >>>> The names of the existing __DATE__ and __TIME__ macros don't >>>> describe >>>> what format they use (for example, that the month name in __DATE__ is in >>>> English and the fields are in a US-centric order), because they don't >>>> need to. A new macro that expands to "2023-08-13" doesn't need to >>>> either. Users of a hypothetical new standard will read the new >>>> specification and will know what it means without having to type the >>>> standard number again every time they use it. >>>> I like the name __ISODATE__ because ISO 8601 is *the* standard that >>>> defines date formats. I don't think there would be any confusion about >>>> which ISO standard is being referenced. (__TIME__ already conforms to >>>> ISO 8601). I'd accept __YYYMMDD__, but since __DATE__ isn't going away, >>>> I'd prefer something that suggests that it's closely related to >>>> __DATE__. Perhaps "__IDATE__". >>> >>> Why __YYYMMDD__ (3 Ys, 2 Ms, 2 Ds). >> Just a typo. I meant __YYYYMMDD__. >> >>> Why not simply __YMD__, which I >>> don't think is taken and is even shorter than __DATE__ . >> Yes, I mentioned __YMD__ in a previous post. >> >>> For additional stability, add a rule in the standard that all 3 >>> date/time macros must refer to the exact same point in time, which must >>> be within the system time tolerance of preprocessing the program source >>> code, possibly even during. For example, if the system only tracks >>> the time in centi-hours (36 seconds each) and preprocessing a >>> particular C >>> program takes 0.1s starting at 2023-08-17T23:59:59, the timestamp >>> used for the macros may be 2023-08-17T23:59:24 or 2023-08-18T00:00:00 . >>> >>> That additional rule above has been carefully written to allow all the >>> following 3 implementations: >>> >>> OK1. When starting the preprocessor, detect the current date and time >>> in a way that doesn't suffer from race conditions, then use that >>> value throughout. >>> >>> OK2. When first expanding either of the 3 macros, capture the >>> date/time value to be used, thus avoiding the I/O cost of doing so >>> when the program doesn't use the value. >>> >>> OK3. When initiating the preprocessing of the program, the user or >>> build script specifies an exact date/time to be used by any >>> available means, such as command line arguments, environment >>> variables, a control file etc. This implementation is particularly >>> useful when trying to produce identical programs at different times >>> and places (so called reproducible builds). >>> >>> But it doesn't allow the following bad implementations: >>> >>> BAD1. Expand all 3 macros to the timestamp of the source file. This >>> would be inconsistent with past implementation practice. >>> >>> BAD2. Capture the date or time every time either macro is expanded. >>> This causes a race condition if time crosses midnight during >>> preprocessing (The example above might end up returning >>> __YMD__ __TIME__ as "2023-08-17" "00:00:00" >> Frankly, I don't think all that is necessary. >> The standard currently says: >> __DATE__ The date of translation of the preprocessing translation unit: >> a character string literal of the form "Mmm dd yyyy", where the >> names of the months are the same as those generated by the >> asctime function, and the first character of dd is a space >> character if the value is less than 10. If the date of >> translation is not available, an implementation-defined valid >> date shall be supplied. >> ... >> __TIME__ The time of translation of the preprocessing translation unit: >> a character string literal of the form "hh:mm:ss" as in the >> time generated by the asctime function. If the time of >> > > Neither quote specifies that the values need to be consistent, nor > that a longer preprocessing time cannot cause an implementation to > provide values indicating when each occurrence is expanded. > >> I think the phrase "translation of the preprocessing translation unit" >> excludes an implementation that expands to a date or time when the line >> is reached, which avoids your BAD2 error crossing midnight. >> Allowing the user to specify a time other than the current one would >> arguably be non-conforming, though a lot of options are non-conforming. >> And both gcc and clang already allow -D__DATE__=... >> I don't think the part about the time being within the system time >> tolerance is necessary. An implementation would have to go out of its >> way not to do that anyway. >> > > The reference to system tolerance was intended as a relaxation to dissuade > implementations from going overboard in trying to get a > correct time, such as by artificially slowing down the preprocessor > to the clock advancement rate. Note that my OK3 implementation > wouldn't be strictly compliant, but could exist in a non-normative > note to inspire such non-normative behavior needed to ensure > compliance with security procedures that validate compilation by > independent recompilation of certified sources. > > > > Enjoy > > Jakob A disadvantage of __YYYYMMDD__ is that it looks to me, at least, as if it is ISO 8601 basic format (e.g. 20230821). The proposal being discussed is using extended format. As I said in a previous post it would be unwieldy to try to capture all the detail. It is better to treat it as a name that is not confusing and can be looked up in the standard to confirm its exact form. -- Pete Forman https://payg.pythonanywhere.com/