Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: How to fix warning: [-Wdate-time] Date: Sun, 16 Apr 2017 13:45:30 -0700 Organization: None to speak of Lines: 69 Message-ID: References: <8e289215-369a-43c5-aa46-9428ad81a224@googlegroups.com> <195fbe3a-b69c-45e4-ac6e-a45a1913a834@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="da8d94982bea82fb3f3cc3c0e5345c5b"; logging-data="2688"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1//9lNj5rIacLB3Vid0Qe+K" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:mfBoyayyZ5Xk5AB4FWw6EF3+ZMk= sha1:7fq2zY4yBVGEoBwUeYY2WNRVI/E= Xref: csiph.com comp.lang.c:108181 supercat@casperkitty.com writes: > On Saturday, April 15, 2017 at 5:02:05 PM UTC-5, Keith Thompson wrote: >> The problem would be that the expansions of __DATE__ and __TIME__ would >> be whatever was passed on the compiler command line and not, as the >> standard specifies and a reader will assume, the date and time of >> translation. > > The Standard does not require any particular degree of precision, nor does > it specify the means via which an implementation would determine the time. > There is no requirement that platforms which host C compilers need to have > any kind of real-time clock functionality. If a compiler included a > command-line option to say "Don't trust the system clock--the time is > actually 1989-06-05 04:32:10, I don't think the Standard would require that > the compiler not believe the command line. Did you check what the standard actually says? For __DATE__, it says that "If the date of translation is not available, an implementation-defined valid date shall be supplied.", and similarly for __TIME__. > Further, in the event that a project happens to be built in multiple steps > that occur days apart, I don't think the Standard specifies which moment in > the build process should be identified by __DATE__ and __TIME__. I would > think a conforming implementation could defer the evaluation of those > strings to build time (the compiler would have to supply place-holder text > and specify everyplace where that text appears within objects' initial > values, but designing that feature into a compiler and linker would not be > difficult). It's "the date [or time] of translation of the preprocessing translation unit", which implies that it's when translation phase 4 is executed (that's when macros are expanded). Of course it can differ for different source files within a project. [...] > It is generally accepted that command-line options may direct a conforming > compiler to behave in non-conforming fashion; if a compiler defines __DATE__ > and __TIME__ before processing -D, and allows the latter definitions to > override the former, that would yield the indicated behavior without the > compiler having to provide any specialized feature to override the build > date and time. It is generally accepted that command-line options can cause a conforming implementation to be non-conforming. "gcc -std=c11 -pedantic" is (let's assume) conforming. "gcc -std=c11 -pedantic -D__DATE__=42" is not. [...] > There are a variety of ways of handling things. If one is using code that > is maintained by someone else and happens to use __DATE__ and __TIME__, > being able to override those without having to edit the source file could > be advantageous, since project management can be easier if imported files > precisely match versions maintained elsewhere. Presumably that code uses __DATE__ and __TIME__ for a reason. Sure, you can do things to break that usage. You're jumping through multiple hoops looking for ways to violate the requirements imposed by the standard. Some of those ways might manage to avoid violating the letter of the standard. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"