Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #108099 > unrolled thread

How to fix warning: [-Wdate-time]

Back to article view | Back to comp.lang.c

Contents

  How to fix warning: [-Wdate-time] MehdiAmini <atorrses@gmail.com> - 2017-04-13 14:44 +0430
    Re: How to fix warning: [-Wdate-time] Barry Schwarz <schwarzb@dqel.com> - 2017-04-13 05:28 -0700
      Re: How to fix warning: [-Wdate-time] MehdiAmini <atorrses@gmail.com> - 2017-04-14 12:55 +0430
        Re: How to fix warning: [-Wdate-time] Keith Thompson <kst-u@mib.org> - 2017-04-14 08:50 -0700
          Re: How to fix warning: [-Wdate-time] Ken Brody <kenbrody@spamcop.net> - 2017-04-14 13:42 -0400
            Re: How to fix warning: [-Wdate-time] James Kuyper <jameskuyper@verizon.net> - 2017-04-14 14:26 -0400
              Re: How to fix warning: [-Wdate-time] David Brown <david.brown@hesbynett.no> - 2017-04-17 16:26 +0200
                Re: How to fix warning: [-Wdate-time] "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-17 10:52 -0400
                  Re: How to fix warning: [-Wdate-time] David Brown <david.brown@hesbynett.no> - 2017-04-17 20:00 +0200
                Re: How to fix warning: [-Wdate-time] Keith Thompson <kst-u@mib.org> - 2017-04-17 08:08 -0700
                  Re: How to fix warning: [-Wdate-time] David Brown <david.brown@hesbynett.no> - 2017-04-17 20:04 +0200
          Re: How to fix warning: [-Wdate-time] Mehdi Amini <atorrses@gmail.com> - 2017-04-15 07:50 +0430
            Re: How to fix warning: [-Wdate-time] Keith Thompson <kst-u@mib.org> - 2017-04-15 15:05 -0700
              Re: How to fix warning: [-Wdate-time] Ken Brody <kenbrody@spamcop.net> - 2017-04-17 11:42 -0400
                Re: How to fix warning: [-Wdate-time] supercat@casperkitty.com - 2017-04-17 08:55 -0700
                Re: How to fix warning: [-Wdate-time] "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-17 11:57 -0400
    Re: How to fix warning: [-Wdate-time] gazelle@shell.xmission.com (Kenny McCormack) - 2017-04-13 13:09 +0000
      Re: How to fix warning: [-Wdate-time] jadill33@gmail.com - 2017-04-13 06:27 -0700
        Re: How to fix warning: [-Wdate-time] supercat@casperkitty.com - 2017-04-15 08:56 -0700
          Re: How to fix warning: [-Wdate-time] Keith Thompson <kst-u@mib.org> - 2017-04-15 15:01 -0700
            Re: How to fix warning: [-Wdate-time] supercat@casperkitty.com - 2017-04-16 11:44 -0700
              Re: How to fix warning: [-Wdate-time] Keith Thompson <kst-u@mib.org> - 2017-04-16 13:45 -0700
                Re: How to fix warning: [-Wdate-time] Ken Brody <kenbrody@spamcop.net> - 2017-04-17 12:14 -0400
              Re: How to fix warning: [-Wdate-time] Ken Brody <kenbrody@spamcop.net> - 2017-04-17 12:06 -0400
                Re: How to fix warning: [-Wdate-time] Keith Thompson <kst-u@mib.org> - 2017-04-17 09:25 -0700
                Re: How to fix warning: [-Wdate-time] "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-17 12:45 -0400
                  Re: How to fix warning: [-Wdate-time] Keith Thompson <kst-u@mib.org> - 2017-04-17 12:02 -0700
                    Re: How to fix warning: [-Wdate-time] "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-17 15:23 -0400
                    Re: How to fix warning: [-Wdate-time] Lowell Gilbert <lgusenet@be-well.ilk.org> - 2017-04-18 13:27 -0400
                      Re: How to fix warning: [-Wdate-time] Ken Brody <kenbrody@spamcop.net> - 2017-04-18 14:23 -0400
                      Re: How to fix warning: [-Wdate-time] Keith Thompson <kst-u@mib.org> - 2017-04-18 12:10 -0700
                  Re: How to fix warning: [-Wdate-time] raltbos@xs4all.nl (Richard Bos) - 2017-04-22 21:20 +0000
                    Re: How to fix warning: [-Wdate-time] James Kuyper <jameskuyper@verizon.net> - 2017-04-22 22:45 -0400
            Re: How to fix warning: [-Wdate-time] Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-17 11:30 -0700
              Re: How to fix warning: [-Wdate-time] Keith Thompson <kst-u@mib.org> - 2017-04-17 12:30 -0700
                Re: How to fix warning: [-Wdate-time] raltbos@xs4all.nl (Richard Bos) - 2017-04-22 21:24 +0000
                  Re: How to fix warning: [-Wdate-time] Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-27 13:33 -0700
                Re: How to fix warning: [-Wdate-time] Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-27 13:26 -0700
      Re: How to fix warning: [-Wdate-time] gordonb.5zr1e@burditt.org (Gordon Burditt) - 2017-04-14 13:35 -0500
        Re: How to fix warning: [-Wdate-time] supercat@casperkitty.com - 2017-04-14 12:17 -0700
          Re: How to fix warning: [-Wdate-time] gordonb.k4gmo@burditt.org (Gordon Burditt) - 2017-04-16 00:04 -0500
          Re: How to fix warning: [-Wdate-time] Noob <root@127.0.0.1> - 2017-04-16 11:04 +0200
            Re: How to fix warning: [-Wdate-time] supercat@casperkitty.com - 2017-04-16 11:52 -0700
            Re: How to fix warning: [-Wdate-time] raltbos@xs4all.nl (Richard Bos) - 2017-04-22 21:28 +0000
      Re: How to fix warning: [-Wdate-time] Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-04-18 21:34 -0600
    Re: How to fix warning: [-Wdate-time] Keith Thompson <kst-u@mib.org> - 2017-04-17 08:09 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#108174

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.

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).
 
> On the other hand, compilers *are* allowed to do that (the option is
> typically "-D" rather than "-d", and the quoting needs to be fixed if
> that's supposed to be part of a shell command line).  The standard
> (6.10.8p2) says that none of the predefined macro names shall be the
> subject of #define or #undef, but that's not a constraint, so it is at
> most undefined behavior -- and the standard doesn't talk about -D.
> gcc prints a warning and allows it.

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.

> On the other other hand, you could always use a different name, perhaps
> 
>     -D__TRANSLATION_TIME__=...
> 
> (I was going to suggest __TIMESTAMP__, but that's already a gcc
> extension.)

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.

[toc] | [prev] | [next] | [standalone]

#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  <http://www.ghoti.net/~kst>
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"

[toc] | [prev] | [next] | [standalone]

#108215

On 4/16/2017 4:45 PM, Keith Thompson wrote:
[...]
> 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.
[...]

But, is that the *start* time, the *end* time, or the *current* time when 
the preprocessor hits the "__TIME__" reference?  (As I previously mentioned, 
what happens if the system clock changes between the time it sees the 
reference in line 1 and the time it sees the reference in line 1000?

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#108212

On 4/16/2017 2:44 PM, supercat@casperkitty.com wrote:
> 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.

NB:  I am in no way a "language lawyer".

Looking at N1256 (yes, I know it's not the latest, but it's the latest I 
have on this computer), section 6.10.8 says this about __DATE__:

     "If the date of translation is not available, an implementation-defined
     valid date shall be supplied."

A similar statement is made about __TIME__.

Without a detailed explanation of what "is not available" means, you could 
easily say that "using compiler flag X will cause the compiler to behave as 
if the date and time are not available" is still conforming.


> 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).

Also, what happens if the computer/compiler isn't that fast, and the file 
takes more than a second to preprocess?  Can __TIME__ at the top of the file 
be different than at the bottom of the file?

Finally, can the time be available at the top of the file, but not at the 
bottom?  (Consider, for example, a hardware clock that for some reason fails 
during the compile.  Or maybe your internet connection to nist.gov goes down.)

I would expect that any non-DS9K compiler would simply get the date/time at 
the start of the compile, and keep using that throughout the compile.  But 
that doesn't mean the Standard requires it.

[...]

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#108218

Ken Brody <kenbrody@spamcop.net> writes:
> On 4/16/2017 2:44 PM, supercat@casperkitty.com wrote:
>> 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.
>
> NB:  I am in no way a "language lawyer".
>
> Looking at N1256 (yes, I know it's not the latest, but it's the latest I 
> have on this computer), section 6.10.8 says this about __DATE__:
>
>      "If the date of translation is not available, an implementation-defined
>      valid date shall be supplied."
>
> A similar statement is made about __TIME__.
>
> Without a detailed explanation of what "is not available" means, you could 
> easily say that "using compiler flag X will cause the compiler to behave as 
> if the date and time are not available" is still conforming.

IMHO, the requirement that the date "is not available" is not satisfied
by an option that tells the compiler to *pretend* the date is not
available.

I'd say that a compiler with that option specified is non-conforming,
simply because it violates the standard's reasonably clear requirements
for __DATE__ and __TIME__.

[...]

> Also, what happens if the computer/compiler isn't that fast, and the file 
> takes more than a second to preprocess?  Can __TIME__ at the top of the file 
> be different than at the bottom of the file?

The standard is less than crystal clear on this point, but I'd say that
a conforming implementation could have __TIME__ and __DATE__ have
different values within a source file.

For that matter, suppose a source file refers to __DATE__ and __TIME__
on the same line:
    printf("%s %s\n", __DATE__, __TIME__);
It's possible that the expansion of __DATE__ could be determined just
before midnight, and the expansion of __TIME__ just after midnight (or
vice versa) resulting in a printed date and time that appear to be off
by 24 hours.

> Finally, can the time be available at the top of the file, but not at the 
> bottom?  (Consider, for example, a hardware clock that for some reason fails 
> during the compile.  Or maybe your internet connection to nist.gov goes down.)

Possibly.

> I would expect that any non-DS9K compiler would simply get the date/time at 
> the start of the compile, and keep using that throughout the compile.  But 
> that doesn't mean the Standard requires it.

GNU cpp (used by gcc) appears to compute the expansion of __DATE__
and __TIME__ once per translation unit, when one of the macros is
encountered for the first time.

I just took a look at the GNU cpp manual.  For __DATE__, it says:

     If GCC cannot determine the current date, it will emit a warning
     message (once per compilation) and '__DATE__' will expand to
     '"??? ?? ????"'.

This contradicts the standard, which says:

    If the date of translation is not available, an
    implementation-defined valid date shall be supplied.

Likewise for __TIME__.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
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"

[toc] | [prev] | [next] | [standalone]

#108223

On 04/17/2017 12:06 PM, Ken Brody wrote:
> On 4/16/2017 2:44 PM, supercat@casperkitty.com wrote:
...
>> 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.
>
> NB:  I am in no way a "language lawyer".
>
> Looking at N1256 (yes, I know it's not the latest, but it's the latest I
> have on this computer), section 6.10.8 says this about __DATE__:
>
>      "If the date of translation is not available, an implementation-defined
>      valid date shall be supplied."
>
> A similar statement is made about __TIME__.
>
> Without a detailed explanation of what "is not available" means, you could
> easily say that "using compiler flag X will cause the compiler to behave as
> if the date and time are not available" is still conforming.

Yes, it would be trivial to support such a flag - but if the date and 
time are in fact available, and the compiler is just pretending 
otherwise, providing any other date and time value renders it 
non-conforming, despite that pretense.

By analogy: if you and I have a formal written agreement that I will pay 
you a specified amount of money to fix my windows, then if I pretend 
that I can't see that your repairs are complete, and therefore refuse to 
pay you, I'm still in violation of our agreement, despite that pretense.

>> 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__.

The standard specifies that __DATE__ describes "The date of translation 
of the preprocessing translation unit:"  "The" is singular: only one 
such data can apply in a given preprocessing translation unit. It's 
entirely consistent with that wording for __DATE__ and __TIME__ to have 
different values in different translation units translated at different 
times, but it would be a very odd compiler that takes several days to 
complete translation of a single preprocessing translation unit. Note, 
in particular, that preprocessing translation units cease to exist by 
the end of translation phase 4; linkage doesn't occur until translation 
phase 8. Therefore, you can't justify waiting for the program to be 
linked together before determining the appropriate value of __DATE__ or 
__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).

Do you really know of any compiler so slow that translation of single 
preprocessing translation unit takes several days to complete?

> Also, what happens if the computer/compiler isn't that fast, and the file
> takes more than a second to preprocess?  Can __TIME__ at the top of the file
> be different than at the bottom of the file?

The standard specifies that __TIME__ is "The time of translation of the 
preprocessing translation unit:". Again, "The" is singular - only one 
time can be associated with any given preprocessing translation unit. It 
seems to me that the only way to assign a single time value to the 
entire thing is to have that time associated with the beginning of 
translation, since, in general, you can't be sure how long the 
translation will take, and you generally need to have a specific value 
for __DATE__ and __TIME__ by the end of translation phase 4 - without 
those specific values, you can't be sure to do with code containing 
those values during phases 5-8. It could be as early as the time when 
the compiler first started up, or as late as the time the __TIME__ macro 
was first translated - but I don't see any reasonable way for it to be 
outside the range bounded by those two times.

> Finally, can the time be available at the top of the file, but not at the
> bottom?  (Consider, for example, a hardware clock that for some reason fails
> during the compile.  Or maybe your internet connection to nist.gov goes down.)

If I'm right about it having to be a single time value, that issue 
doesn't come up.

[toc] | [prev] | [next] | [standalone]

#108239

"James R. Kuyper" <jameskuyper@verizon.net> writes:
[...]
>> On 4/16/2017 2:44 PM, supercat@casperkitty.com wrote:
[...]
>>> 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__.
>
> The standard specifies that __DATE__ describes "The date of translation 
> of the preprocessing translation unit:"  "The" is singular: only one 
> such data can apply in a given preprocessing translation unit. It's 
> entirely consistent with that wording for __DATE__ and __TIME__ to have 
> different values in different translation units translated at different 
> times, but it would be a very odd compiler that takes several days to 
> complete translation of a single preprocessing translation unit. Note, 
> in particular, that preprocessing translation units cease to exist by 
> the end of translation phase 4; linkage doesn't occur until translation 
> phase 8. Therefore, you can't justify waiting for the program to be 
> linked together before determining the appropriate value of __DATE__ or 
> __TIME__.
[...]

It wouldn't have to take several days for the problem to occur.

If translation phase 4 starts at 2017-04-17 23:59:59.99 and completes 20
milliseconds later at 2017-04-18 00:00:00.01, then the start and end
times would be on two different days.  If __DATE__ and __TIME__ are
evaluated separately, you could end up with __DATE__ = "Apr 17 2017" and
__TIME__ = "00:00:00", implying a time 24 hours before the actual
translation time.

The use of the phrases "*The* date" and "*The* time" suggest, though
perhaps not strongly enough, that both __DATE__ and __TIME__ should
correspond to a single moment in time for each translation of each
translation unit.  (A compiler might perform different phases at
different times, but only phase 4 is relevant here.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
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"

[toc] | [prev] | [next] | [standalone]

#108241

On 04/17/2017 03:02 PM, Keith Thompson wrote:
> "James R. Kuyper" <jameskuyper@verizon.net> writes:
> [...]
>>> On 4/16/2017 2:44 PM, supercat@casperkitty.com wrote:
> [...]
>>>> 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__.
>>
>> The standard specifies that __DATE__ describes "The date of translation
>> of the preprocessing translation unit:"  "The" is singular: only one
>> such data can apply in a given preprocessing translation unit. It's
>> entirely consistent with that wording for __DATE__ and __TIME__ to have
>> different values in different translation units translated at different
>> times, but it would be a very odd compiler that takes several days to
>> complete translation of a single preprocessing translation unit. Note,
>> in particular, that preprocessing translation units cease to exist by
>> the end of translation phase 4; linkage doesn't occur until translation
>> phase 8. Therefore, you can't justify waiting for the program to be
>> linked together before determining the appropriate value of __DATE__ or
>> __TIME__.
> [...]
>
> It wouldn't have to take several days for the problem to occur.
>
> If translation phase 4 starts at 2017-04-17 23:59:59.99 and completes 20
> milliseconds later at 2017-04-18 00:00:00.01, then the start and end
> times would be on two different days.  If __DATE__ and __TIME__ are
> evaluated separately, you could end up with __DATE__ = "Apr 17 2017" and
> __TIME__ = "00:00:00", implying a time 24 hours before the actual
> translation time.

Agreed - I was responding to supercat's comment about "... a project 
happens to be built in multiple steps that occur days apart ...", and 
not to the problem itself. It's pretty clear he was thinking about 
building of an entire program, for which that wording would be more 
reasonable, rather than the translation of a single preprocessing 
translation unit.

> The use of the phrases "*The* date" and "*The* time" suggest, though
> perhaps not strongly enough, that both __DATE__ and __TIME__ should
> correspond to a single moment in time for each translation of each
> translation unit.  (A compiler might perform different phases at
> different times, but only phase 4 is relevant here.)

Exactly.

[toc] | [prev] | [next] | [standalone]

#108280

Keith Thompson <kst-u@mib.org> writes:

> The use of the phrases "*The* date" and "*The* time" suggest, though
> perhaps not strongly enough, that both __DATE__ and __TIME__ should
> correspond to a single moment in time for each translation of each
> translation unit.  (A compiler might perform different phases at
> different times, but only phase 4 is relevant here.)

Not to mention that the first thing specified about "Predefined macro
names" is:
     "The values of the predefined macros listed in the following
     subclauses) (except for __FILE__ and __LINE__) remain constant
     throughout the translation unit."

-- 
Lowell Gilbert, embedded/networking software engineer
	 http://be-well.ilk.org/~lowell/

[toc] | [prev] | [next] | [standalone]

#108281

On 4/18/2017 1:27 PM, Lowell Gilbert wrote:
[...]
> Not to mention that the first thing specified about "Predefined macro
> names" is:
>      "The values of the predefined macros listed in the following
>      subclauses) (except for __FILE__ and __LINE__) remain constant
>      throughout the translation unit."

And there is our answer.

It's also in N1256, though worded differently -- 6.10.8.3:

     The values of the predefined macros (except for __FILE__ and
     __LINE__) remain constant throughout the translation unit.

Thanks.

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#108282

Lowell Gilbert <lgusenet@be-well.ilk.org> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> The use of the phrases "*The* date" and "*The* time" suggest, though
>> perhaps not strongly enough, that both __DATE__ and __TIME__ should
>> correspond to a single moment in time for each translation of each
>> translation unit.  (A compiler might perform different phases at
>> different times, but only phase 4 is relevant here.)
>
> Not to mention that the first thing specified about "Predefined macro
> names" is:
>      "The values of the predefined macros listed in the following
>      subclauses) (except for __FILE__ and __LINE__) remain constant
>      throughout the translation unit."

Well that settles it, then.

Note to self: Check the parent sections before posting.  For example, if
you find something in section 6.10.8.1, also read the introductory
material in 6.10.8 and 6.10.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
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"

[toc] | [prev] | [next] | [standalone]

#108352

"James R. Kuyper" <jameskuyper@verizon.net> wrote:

> On 04/17/2017 12:06 PM, Ken Brody wrote:

> > Looking at N1256 (yes, I know it's not the latest, but it's the latest I
> > have on this computer), section 6.10.8 says this about __DATE__:
> >
> >      "If the date of translation is not available, an implementation-defined
> >      valid date shall be supplied."
> >
> > A similar statement is made about __TIME__.
> >
> > Without a detailed explanation of what "is not available" means, you could
> > easily say that "using compiler flag X will cause the compiler to behave as
> > if the date and time are not available" is still conforming.
> 
> Yes, it would be trivial to support such a flag - but if the date and 
> time are in fact available, and the compiler is just pretending 
> otherwise, providing any other date and time value renders it 
> non-conforming, despite that pretense.
> 
> By analogy: if you and I have a formal written agreement that I will pay 
> you a specified amount of money to fix my windows, then if I pretend 
> that I can't see that your repairs are complete, and therefore refuse to 
> pay you, I'm still in violation of our agreement, despite that pretense.

On the other hand, if I have a Moroccan restaurant and one of my dishes
is a tajine with chicken, dates, tomatoes and ras el hanout; and you
order that tajine but say "hold the dates, please"; then I am not in
contravention of any Trading Standards Act if I serve it to you without.

Analogies, I'm afraid, make good illustrations but bad rules.

Richard

[toc] | [prev] | [next] | [standalone]

#108360

On 04/22/2017 05:20 PM, Richard Bos wrote:
> "James R. Kuyper" <jameskuyper@verizon.net> wrote:
> 
>> On 04/17/2017 12:06 PM, Ken Brody wrote:
> 
>>> Looking at N1256 (yes, I know it's not the latest, but it's the latest I
>>> have on this computer), section 6.10.8 says this about __DATE__:
>>>
>>>      "If the date of translation is not available, an implementation-defined
>>>      valid date shall be supplied."
>>>
>>> A similar statement is made about __TIME__.
>>>
>>> Without a detailed explanation of what "is not available" means, you could
>>> easily say that "using compiler flag X will cause the compiler to behave as
>>> if the date and time are not available" is still conforming.
>>
>> Yes, it would be trivial to support such a flag - but if the date and 
>> time are in fact available, and the compiler is just pretending 
>> otherwise, providing any other date and time value renders it 
>> non-conforming, despite that pretense.
>>
>> By analogy: if you and I have a formal written agreement that I will pay 
>> you a specified amount of money to fix my windows, then if I pretend 
>> that I can't see that your repairs are complete, and therefore refuse to 
>> pay you, I'm still in violation of our agreement, despite that pretense.
> 
> On the other hand, if I have a Moroccan restaurant and one of my dishes
> is a tajine with chicken, dates, tomatoes and ras el hanout; and you
> order that tajine but say "hold the dates, please"; then I am not in
> contravention of any Trading Standards Act if I serve it to you without.
> 
> Analogies, I'm afraid, make good illustrations but bad rules.

I don't see a problem with either analogy. Your analogy corresponds to
to a case where someone wants non-conforming behavior from a compiler,
non-conforming behavior that the compiler promises to provide if the
appropriate option is selected. It's perfectly true that they have no
legitimate grounds for complaint if they get that behavior when choosing
that option. But it's also still true that the behavior is
non-conforming. I was objecting to the claim that the implementation
could be considered "still conforming" - I wasn't saying anything about
whether or not the users would be happy to see it fail to conform in
that fashion - obviously they would be if their use of that option was
deliberate.

[toc] | [prev] | [next] | [standalone]

#108235

Keith Thompson <kst-u@mib.org> writes:

> [.. what if -D__DATE__=... or -D__DATE__=... is given? ..]
>
> 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.
>
> On the other hand, compilers *are* allowed to do that (the option is
> typically "-D" rather than "-d", and the quoting needs to be fixed if
> that's supposed to be part of a shell command line).  The standard
> (6.10.8p2) says that none of the predefined macro names shall be the
> subject of #define or #undef, but that's not a constraint, so it is at
> most undefined behavior -- and the standard doesn't talk about -D.
> [...]

Under the provisions of 7.1.3, any definition (ie, and not just #define)
of such names gives undefined behavior.

Also, the documentation for gcc says about -Dname=definition "[t]he
contents of definition are tokenized and processed as if they appeared
during translation phase three in a #define directive."  That too
means undefined behavior.

The documentation for clang says that -Dmacroname=value "[a]dds an
implicit #define into the predefines buffer which is read before the
source file is preprocessed."  Also undefined behavior.

Most likely using -D to give a value to __DATE__ or __TIME__ will
work fine and do what everyone expects.  As far as the Standard
is concerned, it looks like it's just undefined behavior.

[toc] | [prev] | [next] | [standalone]

#108242

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>
>> [.. what if -D__DATE__=... or -D__DATE__=... is given? ..]
>>
>> 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.
>>
>> On the other hand, compilers *are* allowed to do that (the option is
>> typically "-D" rather than "-d", and the quoting needs to be fixed if
>> that's supposed to be part of a shell command line).  The standard
>> (6.10.8p2) says that none of the predefined macro names shall be the
>> subject of #define or #undef, but that's not a constraint, so it is at
>> most undefined behavior -- and the standard doesn't talk about -D.
>> [...]
>
> Under the provisions of 7.1.3, any definition (ie, and not just #define)
> of such names gives undefined behavior.

That's questionable IMHO.  It says the behavior is undefined if the
*program* declares, defines, or undefines a reserved identifier.
Arguably if I compile with `gcc -D__DATE__=...`, it's not the program
that's defining it.  A minor quibble, and ...

> Also, the documentation for gcc says about -Dname=definition "[t]he
> contents of definition are tokenized and processed as if they appeared
> during translation phase three in a #define directive."  That too
> means undefined behavior.
>
> The documentation for clang says that -Dmacroname=value "[a]dds an
> implicit #define into the predefines buffer which is read before the
> source file is preprocessed."  Also undefined behavior.
> 
> Most likely using -D to give a value to __DATE__ or __TIME__ will
> work fine and do what everyone expects.  As far as the Standard
> is concerned, it looks like it's just undefined behavior.

Agreed.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
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"

[toc] | [prev] | [next] | [standalone]

#108354

Keith Thompson <kst-u@mib.org> wrote:

> Tim Rentsch <txr@alumni.caltech.edu> writes:

> > Under the provisions of 7.1.3, any definition (ie, and not just #define)
> > of such names gives undefined behavior.
> 
> That's questionable IMHO.  It says the behavior is undefined if the
> *program* declares, defines, or undefines a reserved identifier.
> Arguably if I compile with `gcc -D__DATE__=...`, it's not the program
> that's defining it.  A minor quibble, and ...

I don't think it's even a minor quibble, and I don't think it even needs
to be argued. It's quite clearly _not_ the program which defines those
constants, but the implementation. After all, if you compiled the same
source code with different options, you'd get a different result. That
the implementation gets the value of its implementation-defined
constants from the command line rather than from an options file or from
its own internal code, _that_ is a minor quibble; it is still perfectly
evident that it _is_ the implementation which defines them, and not the
source under translation.

Richard

[toc] | [prev] | [next] | [standalone]

#108622

raltbos@xs4all.nl (Richard Bos) writes:

> Keith Thompson <kst-u@mib.org> wrote:
>
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>
>>> Under the provisions of 7.1.3, any definition (ie, and not just #define)
>>> of such names gives undefined behavior.
>>
>> That's questionable IMHO.  It says the behavior is undefined if the
>> *program* declares, defines, or undefines a reserved identifier.
>> Arguably if I compile with `gcc -D__DATE__=...`, it's not the program
>> that's defining it.  A minor quibble, and ...
>
> I don't think it's even a minor quibble, and I don't think it even needs
> to be argued.  It's quite clearly _not_ the program which defines those
> constants, but the implementation.  [...]

Oh I can't agree with that.  Whether the setting of __DATE__ or
whatever is part of the program or part of something else depends
on how the compiler defines the semantics of the option in
question.  If the stated semantics are to add a #define to the
program, then the setting is part of the program (and so is
undefined behavior).  Conversely, if there is an option that is
specified as not changing the program but causes the compiler to
use a different value for __DATE__, then the change isn't part of
the program (and presumably is implementation-defined behavior,
or perhaps an extension, but in any case not undefined behavior).

[toc] | [prev] | [next] | [standalone]

#108621

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>
>>> [.. what if -D__DATE__=... or -D__DATE__=... is given? ..]
>>>
>>> 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.
>>>
>>> On the other hand, compilers *are* allowed to do that (the option is
>>> typically "-D" rather than "-d", and the quoting needs to be fixed if
>>> that's supposed to be part of a shell command line).  The standard
>>> (6.10.8p2) says that none of the predefined macro names shall be the
>>> subject of #define or #undef, but that's not a constraint, so it is at
>>> most undefined behavior -- and the standard doesn't talk about -D.
>>> [...]
>>
>> Under the provisions of 7.1.3, any definition (ie, and not just #define)
>> of such names gives undefined behavior.
>
> That's questionable IMHO.  It says the behavior is undefined if the
> *program* declares, defines, or undefines a reserved identifier.
> Arguably if I compile with `gcc -D__DATE__=...`, it's not the program
> that's defining it.  A minor quibble [...]

That's a fair point.  Certainly there could be a compiler option
defined in such a way that __DATE__ or __TIME__ could be set
without running afoul of 7.1.3.

[toc] | [prev] | [next] | [standalone]

#108144

Warnings like -Wdate-time are intended for pedants who need to
exactly match source code to object code.  If you aren't a pedant,
don't use it.  

For those who insist that everyone must always turn on all warnings:
A warning like -Weverything should always produce a warning that
-Weverything is turned on, plus warnings about all unimplemented
warnings (hint:  there are an infinite number of unimplemented
warnings).  It should also warn about compilations done third shift
(e.g. 1AM - 9AM) and on holidays as coding done during these times
is more likely to have errors in it, and it should warn if compilation
is done on Friday the 13th (bad luck) or during a full moon
(werewolves).

Reproducing the exact binary from source can be important for testing
compilers.  The triple-compile test is often done to bootstrap
compilers from an unknown version of an unknown compiler to get to
a known version of a known compiler.  GCC builds from source use
this.  It's also a pretty sensitive test for finding bugs when
working on code-generation or optimization in a compiler.

It can also be an issue for determining if the software has been
tampered with (e.g. viruses) after it has been certified, say, in
voting machine software or FAA-approved flight control software.
Comparing checksums of a known-good binary also works, but it may
not be enough when the source code is subpoenaed in court and proof
demanded that it is the real source code matching what Flight 666
was running when it crashed.

A "computer archeologist" may be tasked with retrieving long-lost
source code from company archives for some ancient binary still in
use so an important fix (say, y2k compliance, or, more relevant
today, January 19, 2038 compliance, when a signed 32-bit UNIX
timestamp overflows.  This may not be much of a problem as a lot
of current UNIX-like software already uses 64-bit timestamps.) can
be made and it is important to determine whether the source code
matches the binary before investing too much effort in applying a
fix, otherwise you may lose long-forgotten but important changes.
Such code may not have reliable version tags, and in any case might
have been subject to binary patches later.  The alternative may be
to reverse-engineer the binary, which can be expensive and
time-consuming.

There is a published instance where a compiler was tampered with,
to (1) insert a back door into the login program, and (2) insert
the tampering with the compiler code into the compilation from clean
source, so that re-building the entire UNIX system from un-tampered-with
source and the binaries of a tampered-with compiler would re-generate
the tampered-with compiler and login program.  This was published
in the Bell Systems Technical Journal in 1984 by Ken Thompson.  As
I recall, the title was something like "Reflections on Trusting
Trust".  Matching source to object code isn't foolproof if the
compiler has been tampered with.



Putting the date or time of compilation into the object code (as
opposed to putting the date or time of modification of the source
code) can cause unimportant but annoying (if you need to check an
exact match) differences.  I'd expect only those who have a need
for checking that the source reproduces the object exactly would
enable warnings like -Wdate-time.

Another possible issue is linkers which stick a time-of-link time
stamp into the executable.  For systems where this cannot be disabled,
you need an object-comparison and executable-comparison tools that
compare every part of the files except the time stamp.  It may also
be that you need tools that ignore differences in the format of or
presence of debugging symbols in the comparison.

A triple-compile test can be very valuable for finding compiler
bugs.  You run one like this:

1.  Compile the compiler source code with any old compiler you've
    got around (such as the last-known-stable version of the compiler
    you are developing, or the compiler your system came with).
    Call the result C1.

2.  Compile the same compiler source code with C1.  Call the result
    C2.

3.  Compile the same compiler source code with C2.  Call the result
    C3.

If C2 and C3 are not identical except for trivial differences
(__DATE__, __TIME__ and __TIMESTAMP__ macros and linker time stamps
would be included here, as would differences in compiler options.
Library differences, if you're not recompiling the libraries each
time, are also expected.  Don't do that when running a triple-compile
test), chances are high that there's a bug either in the compiler
being built, or perhaps the compiler you started with.  C1 and C2
may legitimately be different as differences in code generation and
optimization are likely.  However, they should generate the same
code when given the same source, so C2 and C3 should not have
differences.

[toc] | [prev] | [next] | [standalone]

#108149

On Friday, April 14, 2017 at 1:35:16 PM UTC-5, Gordon Burditt wrote:
> A triple-compile test can be very valuable for finding compiler
> bugs.  You run one like this:
> 
> 1.  Compile the compiler source code with any old compiler you've
>     got around (such as the last-known-stable version of the compiler
>     you are developing, or the compiler your system came with).
>     Call the result C1.
> 
> 2.  Compile the same compiler source code with C1.  Call the result
>     C2.
> 
> 3.  Compile the same compiler source code with C2.  Call the result
>     C3.

How about taking any two compilers one has lying around, and compiling
the compiler source with each, then with the compilers produced thereby,
and then with the compilers produced by those.  That would ensure that
any secret code-tampering logic which was present in either of the
originals couldn't undetectably alter the results unless the exact same
code-tampering logic was present in both originals.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web