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 1 of 3  [1] 2 3  Next page →

#108099 — How to fix warning: [-Wdate-time]

Hi,
I tried to improve upon my_err function, but I get two warnings:

#define BUFF_SIZE 256
#define my_err(...) \
	do { \
		char buff[BUFF_SIZE]; \
		fprintf(stderr,"\n"); \
		snprintf(buff, sizeof(buff),__FILE__); \
		fprintf(stderr,"FILE:"); \
         	fprintf(stderr,"%s\n" ,buff); \
         	snprintf(buff, sizeof(buff),__FUNCTION__); \
		fprintf(stderr,"FUNCTION:"); \
         	fprintf(stderr,"%s\n" ,buff); \
         	fprintf(stderr,"LINE:%d\n",__LINE__); \
         	snprintf(buff, sizeof(buff),__VA_ARGS__); \
		my_err_s(buff); \
	} while (0)


noreturn void my_err_s(const char * const s)
{
	if ((s == NULL) || (*s == '\0'))
	{
		fprintf(stderr, "Please provide a proper message for "
			 "my_err function.\n");
		exit(EXIT_FAILURE);
	}

	fprintf(stderr,"DATE:%s\n",__DATE__);
	fprintf(stderr,"TIME:%s\n",__TIME__);

	fprintf(stderr, "\nERROR:%s\n", s);
	exit(EXIT_FAILURE);
}

warning: expansion of date or time macro is not reproducible [-Wdate-time]
         fprintf(stderr,"DATE:%s\n",__DATE__);
                                    ^

warning: expansion of date or time macro is not reproducible [-Wdate-time]
         fprintf(stderr,"TIME:%s\n",__TIME__);
                                    ^

What to do to fix the warnings?

-- 
www.my-c-codes.com/

Farewell.

[toc] | [next] | [standalone]

#108100

On Thu, 13 Apr 2017 14:44:02 +0430, MehdiAmini <atorrses@gmail.com>
wrote:

>Hi,
>I tried to improve upon my_err function, but I get two warnings:
>
>#define BUFF_SIZE 256
>#define my_err(...) \
>	do { \
>		char buff[BUFF_SIZE]; \
>		fprintf(stderr,"\n"); \
>		snprintf(buff, sizeof(buff),__FILE__); \
>		fprintf(stderr,"FILE:"); \
>         	fprintf(stderr,"%s\n" ,buff); \

Why do you use three function calls and an unnecessary buffer when the
simpler and easier to read equivalent
   fprintf(stderr, "FILE:%s\n", __FILE__);
is available?

Additionally, on some systems, the file name can contain the '%'
character.  If it does so, then statements of the form
   snprintf(buff, sizeof(buff),__FILE__); 
can cause undefined behavior.  When attempting to print a string over
whose content you have no control, using
   snprintf(buff, sizeof(buff),"%s",__FILE__); 
will avoid the potential undefined behavior.

<snip>

>	fprintf(stderr,"DATE:%s\n",__DATE__);
>	fprintf(stderr,"TIME:%s\n",__TIME__);
>
>	fprintf(stderr, "\nERROR:%s\n", s);
>	exit(EXIT_FAILURE);
>}
>
>warning: expansion of date or time macro is not reproducible [-Wdate-time]
>         fprintf(stderr,"DATE:%s\n",__DATE__);
>                                    ^
>
>warning: expansion of date or time macro is not reproducible [-Wdate-time]
>         fprintf(stderr,"TIME:%s\n",__TIME__);
>                                    ^
>
>What to do to fix the warnings?

This warning is an optional feature of your compiler.  If you do not
want it, you should not specify the option that activates it.
Alternately, you could specify the option that deactivates it.  How to
perform either action is a discussion for a group where your compiler
is topical.  This has nothing to do with the C language itself.

-- 
Remove del for email

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

#108118

On 04/13/2017 04:58 PM, Barry Schwarz wrote:
> On Thu, 13 Apr 2017 14:44:02 +0430, MehdiAmini <atorrses@gmail.com>
> wrote:

[...]

>> What to do to fix the warnings?
>
> This warning is an optional feature of your compiler.  If you do not
> want it, you should not specify the option that activates it.
> Alternately, you could specify the option that deactivates it.  How to
> perform either action is a discussion for a group where your compiler
> is topical.  This has nothing to do with the C language itself.
>

For my Clang compiler, three #pragma did the job to deactivate it in a 
certain place.

-- 
www.my-c-codes.com/

Farewell.

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

#108133

MehdiAmini <atorrses@gmail.com> writes:
> On 04/13/2017 04:58 PM, Barry Schwarz wrote:
>> On Thu, 13 Apr 2017 14:44:02 +0430, MehdiAmini <atorrses@gmail.com>
>> wrote:
>
> [...]
>
>>> What to do to fix the warnings?
>>
>> This warning is an optional feature of your compiler.  If you do not
>> want it, you should not specify the option that activates it.
>> Alternately, you could specify the option that deactivates it.  How to
>> perform either action is a discussion for a group where your compiler
>> is topical.  This has nothing to do with the C language itself.
>
> For my Clang compiler, three #pragma did the job to deactivate it in a 
> certain place.

What #pragma?

Why can't you just invoke the compiler without the "-Wdate-time" option,
or with "-Wno-date-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]

#108139

On 4/14/2017 11:50 AM, Keith Thompson wrote:
> MehdiAmini <atorrses@gmail.com> writes:
>> On 04/13/2017 04:58 PM, Barry Schwarz wrote:
>>> On Thu, 13 Apr 2017 14:44:02 +0430, MehdiAmini <atorrses@gmail.com>
>>> wrote:
>>
>> [...]
>>
>>>> What to do to fix the warnings?
>>>
>>> This warning is an optional feature of your compiler.  If you do not
>>> want it, you should not specify the option that activates it.
>>> Alternately, you could specify the option that deactivates it.  How to
>>> perform either action is a discussion for a group where your compiler
>>> is topical.  This has nothing to do with the C language itself.
>>
>> For my Clang compiler, three #pragma did the job to deactivate it in a
>> certain place.
>
> What #pragma?
>
> Why can't you just invoke the compiler without the "-Wdate-time" option,
> or with "-Wno-date-time"?

Sometimes you only want to disable a warning for a particular piece of code. 
  Why force an entire project to be compiled with "-Wno-date-time" for one 
macro?

-- 
Kenneth Brody

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

#108143

On 04/14/2017 01:42 PM, Ken Brody wrote:
> On 4/14/2017 11:50 AM, Keith Thompson wrote:
...
>> Why can't you just invoke the compiler without the "-Wdate-time" option,
>> or with "-Wno-date-time"?
> 
> Sometimes you only want to disable a warning for a particular piece of code. 
>   Why force an entire project to be compiled with "-Wno-date-time" for one 
> macro?

Because the entire project is one for which the motivations for that
warning don't apply? It is really a rather obscure issue to be warning
about.

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

#108201

On 14/04/17 20:26, James Kuyper wrote:
> On 04/14/2017 01:42 PM, Ken Brody wrote:
>> On 4/14/2017 11:50 AM, Keith Thompson wrote:
> ...
>>> Why can't you just invoke the compiler without the "-Wdate-time" option,
>>> or with "-Wno-date-time"?
>>
>> Sometimes you only want to disable a warning for a particular piece of code.
>>   Why force an entire project to be compiled with "-Wno-date-time" for one
>> macro?
>
> Because the entire project is one for which the motivations for that
> warning don't apply? It is really a rather obscure issue to be warning
> about.
>

IMHO, it is a very good thing to be warning about.  If your program 
contains the macros __DATA__ or __TIME__, then your builds are not 
reproducible.  I cannot think of any other way to make a build 
non-deterministic, at least on compilers I have used.

That means that as long as you avoid these macros, you can use the 
generated binary file as a way to check that you have exactly the same 
build as on a previous occasion.  If you are working on software where 
you need to check or qualify your builds in a particular manner, this is 
essential.

So my thoughts about how to "fix" this warning is simply to avoid using 
__DATE__ or __TIME__.

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

#108202

On 04/17/2017 10:26 AM, David Brown wrote:
> On 14/04/17 20:26, James Kuyper wrote:
>> On 04/14/2017 01:42 PM, Ken Brody wrote:
...
>>>   Why force an entire project to be compiled with "-Wno-date-time" for one
>>> macro?
>>
>> Because the entire project is one for which the motivations for that
>> warning don't apply? It is really a rather obscure issue to be warning
>> about.
>>
>
> IMHO, it is a very good thing to be warning about.  If your program
> contains the macros __DATA__ or __TIME__, then your builds are not
> reproducible.  I cannot think of any other way to make a build
> non-deterministic, at least on compilers I have used.
>
> That means that as long as you avoid these macros, you can use the
> generated binary file as a way to check that you have exactly the same
> build as on a previous occasion.

That's not a particularly useful thing to test with most of the software 
I work on. As a general rule, if I'm compiling the code, something has 
changed: the source code, one of the libraries it's connected to, the 
compiler itself, or the operating system. The normal expectation is that 
the generated binary file is NOT the same as any previously created.
In fact, in the past, we've used a version control system which included 
a specialized variant of "make" which automatically checked whether all 
files opened during a previous build of an object file (including all 
#include files (recursively) and the compiler itself) still have the 
same version they had during that build, and that all environment 
variables have the same values they had during the previous build. If 
so, it would restore a copy of the object file created by that previous 
build, rather than rebuilding it. The object files themselves had 
versions, and the same logic was used when linking them together in an 
executable. We're not using that system anymore, but not because of that 
feature - we found it rather convenient

One of the first things several of my programs do when executed is put a 
message in the status log containing the version number of the file that 
contains the code which caused that message to be printed, along with 
the current values of __DATE__ and __TIME__. I've found that information 
to be fairly useful; more useful than knowing whether the object files 
were identical to those created by a previous build.

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

#108231

On 17/04/17 16:52, James R. Kuyper wrote:
> On 04/17/2017 10:26 AM, David Brown wrote:
>> On 14/04/17 20:26, James Kuyper wrote:
>>> On 04/14/2017 01:42 PM, Ken Brody wrote:
> ...
>>>>   Why force an entire project to be compiled with "-Wno-date-time"
>>>> for one
>>>> macro?
>>>
>>> Because the entire project is one for which the motivations for that
>>> warning don't apply? It is really a rather obscure issue to be warning
>>> about.
>>>
>>
>> IMHO, it is a very good thing to be warning about.  If your program
>> contains the macros __DATA__ or __TIME__, then your builds are not
>> reproducible.  I cannot think of any other way to make a build
>> non-deterministic, at least on compilers I have used.
>>
>> That means that as long as you avoid these macros, you can use the
>> generated binary file as a way to check that you have exactly the same
>> build as on a previous occasion.
>
> That's not a particularly useful thing to test with most of the software
> I work on. As a general rule, if I'm compiling the code, something has
> changed: the source code, one of the libraries it's connected to, the
> compiler itself, or the operating system. The normal expectation is that
> the generated binary file is NOT the same as any previously created.
> In fact, in the past, we've used a version control system which included
> a specialized variant of "make" which automatically checked whether all
> files opened during a previous build of an object file (including all
> #include files (recursively) and the compiler itself) still have the
> same version they had during that build, and that all environment
> variables have the same values they had during the previous build. If
> so, it would restore a copy of the object file created by that previous
> build, rather than rebuilding it. The object files themselves had
> versions, and the same logic was used when linking them together in an
> executable. We're not using that system anymore, but not because of that
> feature - we found it rather convenient
>
> One of the first things several of my programs do when executed is put a
> message in the status log containing the version number of the file that
> contains the code which caused that message to be printed, along with
> the current values of __DATE__ and __TIME__. I've found that information
> to be fairly useful; more useful than knowing whether the object files
> were identical to those created by a previous build.

The requirements for this sort of thing vary greatly - for some kinds of 
development work, __DATE__ and __TIME__ are /exactly/ what you need. 
For others, they are exactly what you /don't/ need.

So it is good for a compiler to have such a warning - and good that the 
warning is entirely optional!

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

#108203

David Brown <david.brown@hesbynett.no> writes:
> On 14/04/17 20:26, James Kuyper wrote:
>> On 04/14/2017 01:42 PM, Ken Brody wrote:
>>> On 4/14/2017 11:50 AM, Keith Thompson wrote:
>> ...
>>>> Why can't you just invoke the compiler without the "-Wdate-time" option,
>>>> or with "-Wno-date-time"?
>>>
>>> Sometimes you only want to disable a warning for a particular piece of code.
>>>   Why force an entire project to be compiled with "-Wno-date-time" for one
>>> macro?
>>
>> Because the entire project is one for which the motivations for that
>> warning don't apply? It is really a rather obscure issue to be warning
>> about.
>>
>
> IMHO, it is a very good thing to be warning about.  If your program 
> contains the macros __DATA__ or __TIME__, then your builds are not 
> reproducible.  I cannot think of any other way to make a build 
> non-deterministic, at least on compilers I have used.
>
> That means that as long as you avoid these macros, you can use the 
> generated binary file as a way to check that you have exactly the same 
> build as on a previous occasion.  If you are working on software where 
> you need to check or qualify your builds in a particular manner, this is 
> essential.
>
> So my thoughts about how to "fix" this warning is simply to avoid using 
> __DATE__ or __TIME__.

Sure, the -Wdate-date option is useful if you need reproducible builds.
But if you're using __DATE__ and __TIME__, then you apparently *don't*
need reproducible builds.

The OP, Mehdi Amini, seems to want to use both -Wdate-time and
__DATE__/__TIME__, and is looking for (and has found) a way to turn off
the effect of -Wdate-time for just one source file.  That seems frankly
silly.

I can imagine using -Wdate-time by default and comparing object files,
and then making an exception for the one source file that uses __DATE__
and __TIME__, but the Mehdi's only stated rationale for using
-Wdate-time is that "IMHO this warning exists for a reason".

-- 
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]

#108232

On 17/04/17 17:08, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 14/04/17 20:26, James Kuyper wrote:
>>> On 04/14/2017 01:42 PM, Ken Brody wrote:
>>>> On 4/14/2017 11:50 AM, Keith Thompson wrote:
>>> ...
>>>>> Why can't you just invoke the compiler without the "-Wdate-time" option,
>>>>> or with "-Wno-date-time"?
>>>>
>>>> Sometimes you only want to disable a warning for a particular piece of code.
>>>>   Why force an entire project to be compiled with "-Wno-date-time" for one
>>>> macro?
>>>
>>> Because the entire project is one for which the motivations for that
>>> warning don't apply? It is really a rather obscure issue to be warning
>>> about.
>>>
>>
>> IMHO, it is a very good thing to be warning about.  If your program
>> contains the macros __DATA__ or __TIME__, then your builds are not
>> reproducible.  I cannot think of any other way to make a build
>> non-deterministic, at least on compilers I have used.
>>
>> That means that as long as you avoid these macros, you can use the
>> generated binary file as a way to check that you have exactly the same
>> build as on a previous occasion.  If you are working on software where
>> you need to check or qualify your builds in a particular manner, this is
>> essential.
>>
>> So my thoughts about how to "fix" this warning is simply to avoid using
>> __DATE__ or __TIME__.
>
> Sure, the -Wdate-date option is useful if you need reproducible builds.
> But if you're using __DATE__ and __TIME__, then you apparently *don't*
> need reproducible builds.

Yes - or you are using the macros without considering the repercussions 
for reproducible builds.  Whatever the OP was thinking originally, I 
hope that by now he knows the pros and cons of using the macros, and can 
make an informed decision.

>
> The OP, Mehdi Amini, seems to want to use both -Wdate-time and
> __DATE__/__TIME__, and is looking for (and has found) a way to turn off
> the effect of -Wdate-time for just one source file.  That seems frankly
> silly.

It might be reasonable to have __DATE__ and __TIME__ as part of code 
that is conditionally compiled in debug or development builds, and 
disabled at a later date.  In such circumstances, you may then want to 
allow the macros in a piece of code that you know will be disabled 
before "real" builds.

>
> I can imagine using -Wdate-time by default and comparing object files,
> and then making an exception for the one source file that uses __DATE__
> and __TIME__, but the Mehdi's only stated rationale for using
> -Wdate-time is that "IMHO this warning exists for a reason".
>

Presumably he now understands this reason, and can decide what he wants 
to do about it.

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

#108155

On 04/14/2017 08:20 PM, Keith Thompson wrote:
> MehdiAmini <atorrses@gmail.com> writes:
>> On 04/13/2017 04:58 PM, Barry Schwarz wrote:
>>> On Thu, 13 Apr 2017 14:44:02 +0430, MehdiAmini <atorrses@gmail.com>
>>> wrote:

[...]

>> For my Clang compiler, three #pragma did the job to deactivate it in a
>> certain place.
>
> What #pragma?
>

See:
http://clang.llvm.org/docs/UsersManual.html#controlling-diagnostics-via-pragmas

My code:
noreturn void my_err_s(const char * const s)
{
	if ((s == NULL) || (*s == '\0'))
     {
		fprintf(stderr, "Please provide a proper message for "
			 "my_err function.\n");
		exit(EXIT_FAILURE);
	}
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wdate-time"

	fprintf(stderr,"DATE:%s\n",__DATE__);
	fprintf(stderr,"TIME:%s\n",__TIME__);

#pragma clang diagnostic pop

	fprintf(stderr, "\nERROR:%s\n", s);
	exit(EXIT_FAILURE);
}


> Why can't you just invoke the compiler without the "-Wdate-time" option,
> or with "-Wno-date-time"?
>

IMHO this warning exists for a reason, so I just disable it for this 
part only.

-- 
www.my-c-codes.com/

Farewell.

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

#108165

Mehdi Amini <atorrses@gmail.com> writes:
> On 04/14/2017 08:20 PM, Keith Thompson wrote:
[...]
>> Why can't you just invoke the compiler without the "-Wdate-time" option,
>> or with "-Wno-date-time"?
>
> IMHO this warning exists for a reason, so I just disable it for this
> part only.

Of course it exists for a reason, but why assume that that reason
applies to you?  If you need bitwise identical output from your
compiler, then the -Wdate-time option is one way to enforce that --
but if you're using __DATE__ and __TIME__ in your code, then you
obviously *don't* need bitwise identical output.  Why on Earth
would you use a compile-time option that enforces something you
don't need -- and then use an compiler-specific macro to override it?

The __DATE__ and __TIME__ macros also exist for a reason.

If you had a reason to use -Wdate-time for most of your code, then using
the #pragma would make sense, but based on what you've said that doesn't
seem to be the case.

-- 
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]

#108206

On 4/15/2017 6:05 PM, Keith Thompson wrote:
> Mehdi Amini <atorrses@gmail.com> writes:
>> On 04/14/2017 08:20 PM, Keith Thompson wrote:
> [...]
>>> Why can't you just invoke the compiler without the "-Wdate-time" option,
>>> or with "-Wno-date-time"?
>>
>> IMHO this warning exists for a reason, so I just disable it for this
>> part only.
>
> Of course it exists for a reason, but why assume that that reason
> applies to you?  If you need bitwise identical output from your
> compiler, then the -Wdate-time option is one way to enforce that --
> but if you're using __DATE__ and __TIME__ in your code, then you
> obviously *don't* need bitwise identical output.  Why on Earth
> would you use a compile-time option that enforces something you
> don't need -- and then use an compiler-specific macro to override it?
>
> The __DATE__ and __TIME__ macros also exist for a reason.
>
> If you had a reason to use -Wdate-time for most of your code, then using
> the #pragma would make sense, but based on what you've said that doesn't
> seem to be the case.

I see two ways to look at this situation:

(1)  "I know that this will trigger the date/time warning if it's enabled, 
so I'll wrap my code with pragmas to turn it off for my section of the code, 
because it's an innocuous warning."

and

(2)  "If the code is being compiled with that warning enabled, then who am I 
to say it's innocuous?  The user turned it on for a reason, and the warning 
should be generated as expected."


Okay, I can see a third way to look at this...


(3)  "I really don't know what the user wants, so I'll wrap the pragmas in 
#if statements, and put a large comment block at the top explaining the 
situation, and says 'if you are running with the date/time warning enabled, 
but don't care about it for this section of the code, then change the 
#define to 1, otherwise leave it at zero', so the user can have control over 
it."

-- 
Kenneth Brody

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

#108210

On Monday, April 17, 2017 at 10:42:43 AM UTC-5, Ken Brody wrote:
> I see two ways to look at this situation:
> 
> (1)  "I know that this will trigger the date/time warning if it's enabled, 
> so I'll wrap my code with pragmas to turn it off for my section of the code, 
> because it's an innocuous warning."
> 
> and
> 
> (2)  "If the code is being compiled with that warning enabled, then who am I 
> to say it's innocuous?  The user turned it on for a reason, and the warning 
> should be generated as expected."

A third possibility would be "The tool I'm using to check binary equivalence
can be told to ignore a certain part of the file, and I want to use the
__DATE__ and __TIME__ macros to initialized some objects that I've forced
into that part of the file, but I want the compiler to squawk if the macros
are used anywhere else."

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

#108211

On 04/17/2017 11:42 AM, Ken Brody wrote:
> On 4/15/2017 6:05 PM, Keith Thompson wrote:
>> Mehdi Amini <atorrses@gmail.com> writes:
>>> On 04/14/2017 08:20 PM, Keith Thompson wrote:
>> [...]
>>>> Why can't you just invoke the compiler without the "-Wdate-time" option,
>>>> or with "-Wno-date-time"?
>>>
>>> IMHO this warning exists for a reason, so I just disable it for this
>>> part only.
>>
>> Of course it exists for a reason, but why assume that that reason
>> applies to you?  If you need bitwise identical output from your
>> compiler, then the -Wdate-time option is one way to enforce that --
>> but if you're using __DATE__ and __TIME__ in your code, then you
>> obviously *don't* need bitwise identical output.  Why on Earth
>> would you use a compile-time option that enforces something you
>> don't need -- and then use an compiler-specific macro to override it?
>>
>> The __DATE__ and __TIME__ macros also exist for a reason.
>>
>> If you had a reason to use -Wdate-time for most of your code, then using
>> the #pragma would make sense, but based on what you've said that doesn't
>> seem to be the case.
>
> I see two ways to look at this situation:
>
> (1)  "I know that this will trigger the date/time warning if it's enabled,
> so I'll wrap my code with pragmas to turn it off for my section of the code,
> because it's an innocuous warning."
>
> and
>
> (2)  "If the code is being compiled with that warning enabled, then who am I
> to say it's innocuous?  The user turned it on for a reason, and the warning
> should be generated as expected."
>
>
> Okay, I can see a third way to look at this...
>
>
> (3)  "I really don't know what the user wants, so I'll wrap the pragmas in
> #if statements, and put a large comment block at the top explaining the
> situation, and says 'if you are running with the date/time warning enabled,
> but don't care about it for this section of the code, then change the
> #define to 1, otherwise leave it at zero', so the user can have control over
> it."

I see a third way of looking at this, which seems to be the one used by 
the OP: "I have no idea what the purpose of this warning is, but since 
it exists, I've decided to turn it on. The warning has triggered for 
this particular piece of code, and there's nothing really wrong with it, 
so I'll use #pragmas to turn the warning off in this particular case."

Either you have a good reason for wanting that warning turned on, in 
which case you should remove the use of __DATE__ and __TIME__ from that 
code, or you have a good reason for using __DATE__ and __TIME__, in 
which case you should turn off that warning for the entire program.

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

#108101

In article <ocnirh$pu4$1@dont-email.me>,
MehdiAmini  <atorrses@gmail.com> wrote:
...
>warning: expansion of date or time macro is not reproducible [-Wdate-time]
>         fprintf(stderr,"DATE:%s\n",__DATE__);
>
>warning: expansion of date or time macro is not reproducible [-Wdate-time]
>         fprintf(stderr,"TIME:%s\n",__TIME__);
>
>What to do to fix the warnings?

Barry has given you the answer - if you don't want these warnings, then do
whatever's necessary to inhibit the warnings.

But I think what you're really asking is "What does this warning mean?"
and I have to admit that I was puzzled as well.  However, "man gcc" shows:

  -Wdate-time
           Warn when macros "__TIME__", "__DATE__" or "__TIMESTAMP__" are
           encountered as they might prevent bit-wise-identical reproducible
           compilations.

which seems pretty pedantic to me.  I doubt anyone really cares about this.

And, to expand on that comment, I've generally found that compilation is
not entirely deterministic - which is to say that I've never relied upon,
nor have I ever assumed, nor have I ever expected to be able to assume or
to rely upon the results of one compilation to be bitwise identical to the
results of any other compilation (even though all inputs and conditions are
otherwise identical).

So, it all seems kind of hinky to me.

-- 
Watching ConservaLoons playing with statistics and facts is like watching a
newborn play with a computer.  Endlessly amusing, but totally unproductive.

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

#108102

On Thursday, April 13, 2017 at 9:09:44 AM UTC-4, Kenny McCormack wrote:
> In article <o...@dont-email.me>,
> MehdiAmini  <a...@gmail.com> wrote:
> ...
> >warning: expansion of date or time macro is not reproducible [-Wdate-time]
> >         fprintf(stderr,"DATE:%s\n",__DATE__);
> >
> >warning: expansion of date or time macro is not reproducible [-Wdate-time]
> >         fprintf(stderr,"TIME:%s\n",__TIME__);
> >
> >What to do to fix the warnings?
> 
> Barry has given you the answer - if you don't want these warnings, then do
> whatever's necessary to inhibit the warnings.
> 
> But I think what you're really asking is "What does this warning mean?"
> and I have to admit that I was puzzled as well.  However, "man gcc" shows:
> 
>   -Wdate-time
>            Warn when macros "__TIME__", "__DATE__" or "__TIMESTAMP__" are
>            encountered as they might prevent bit-wise-identical reproducible
>            compilations.
> 
> which seems pretty pedantic to me.  I doubt anyone really cares about this.
> 
> And, to expand on that comment, I've generally found that compilation is
> not entirely deterministic - which is to say that I've never relied upon,
> nor have I ever assumed, nor have I ever expected to be able to assume or
> to rely upon the results of one compilation to be bitwise identical to the
> results of any other compilation (even though all inputs and conditions are
> otherwise identical).
> 
> So, it all seems kind of hinky to me.

It can be important when one group absorbs the code from another group,
and they need to have a build process that produces exact binaries.  This
can happen in the government where contractors that develop software for a
government program, and then the contract is up and the government takes
over development and maintenance.

Often binary equivalence is desired when software accreditation is done,
like safe for flight or when other regulatory testing is required.  This
is quite expensive, so being able to reproduce exact binaries implies that
if your software is made out of many modules, and you change the source
in such a way that only part of your modules have a binary difference, then
there's no need to put the executables that weren't binary altered through
the expensive testing process.  This is also how one can get stuck using a
*really* old compiler.

Best regards,
John D.

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

#108162

On Thursday, April 13, 2017 at 8:28:01 AM UTC-5, jadi...@gmail.com wrote:
> It can be important when one group absorbs the code from another group,
> and they need to have a build process that produces exact binaries.  This
> can happen in the government where contractors that develop software for a
> government program, and then the contract is up and the government takes
> over development and maintenance.

Out of curiosity, would there be any problem with a compiler allowing a
programmer to use command-line options like:

  -d__DATE__=\"Jan 01 1980\" -d__TIME__=\"00:00:00\"

to override the default definitions of those macros?  Or else having the
macros expand in a way which would be guaranteed to produce a diagnostic?

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

#108164

supercat@casperkitty.com writes:
> On Thursday, April 13, 2017 at 8:28:01 AM UTC-5, jadi...@gmail.com wrote:
>> It can be important when one group absorbs the code from another group,
>> and they need to have a build process that produces exact binaries.  This
>> can happen in the government where contractors that develop software for a
>> government program, and then the contract is up and the government takes
>> over development and maintenance.
>
> Out of curiosity, would there be any problem with a compiler allowing a
> programmer to use command-line options like:
>
>   -d__DATE__=\"Jan 01 1980\" -d__TIME__=\"00:00:00\"
>
> to override the default definitions of those macros?  Or else having the
> macros expand in a way which would be guaranteed to produce a diagnostic?

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.
gcc prints a warning and allows it.

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

-- 
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]

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web