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 3 of 3 — ← Prev page 1 2 [3]

#108167

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

You forgot to explicitly state the step where you compare the final
executables for each set of compilations against each other.  It's
important, even though I know that's what was meant.

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

That's fine as far as it goes.  It doesn't handle a number of other
possible problems for the paranoid:

- If you pick two versions of GCC (or two versions from any other
  vendor), there's a high probability that if one was tampered with
  at the vendor, the tampering is also present in a later version.

- If you pick two very different compilers, they don't run on the
  same platform or generate code for the same CPU and the same OS,
  making the executables nothing alike.

- The OS has been tampered with to make the compiler act differently.

- The hypervisor has been tampered with to make the compiler act
  differently.

- The CPU has been tampered with to make the compiler act differently.
  Do you really think Intel and AMD and other CPU manufacturers
  haven't been compromised by the NSA?

- The tampering is in the C library, not the compiler proper, and
  all compilers for the platform use the same C library (msvcrt.dll,
  anyone?)  Nobody ever recompiles it because they don't have the
  source code (I presume:  Microsoft rarely makes source code
  available, and I'm guessing msvcrt.dll is no exception.)

Also, the triple-compile test is really much more useful for
discovering accidental bugs, not intentional tampering where the
tamperer may try to interfere with any tests you might run, or
conveniently kill you with an explosion in your cell phone battery
before the test results are in.

I do recall a similar problem of hidden data transfer from a tool
to its output that really happened:  long, long ago.  The tool was
a z80 assembler running on a TRS-80 Model II.  Building it usually
used a previously known-good version of that same assembler.

1.  At one point, the feature was added to permit using the name
    of an opcode as a symbol that had as its value the value of the
    machine opcode.  The opcode table had fields like opcode name,
    machine opcode value, what type of arguments it took (registers,
    1-byte immediate data, 2-byte immediate data, address, etc.)
    and the address of a handler that processed that opcode.

2.  At a later point, the assembler was changed to use feature #1
    in its opcode table.

Much later, someone complains that the opcode value generated by
one of the more obscure z80 opcodes was wrong. (OTIR, I think.)  I
look at the output of the sample code given, then reproduce it.  I
then look at the manuals for the z80 processor.  Yep, it's wrong.
Further, the assembler produced the same opcode value for two
different opcode names, so it was unlikely to be a typo introduced
into the manufacturer documentation after the assembler was written.
So I then go to the source code.  There's no place in the source
code where the value of that opcode appears!

Ever since change #2, the values of the opcodes were passed down
from predecessor to the current version.  Patching the binary, then
rebuilding from unchanged source using the fixed assembler (which
would re-create the binary with the patch already in it!) would fix
it.

I think the real fix was to revert change #2 above.  This was done
very carefully, as there were many unrelated changes done since
then:

	1.  replace in the opcode table the symbol with the value
	    of the opcode, except DO NOT fix the incorrect opcode
	    (which the assembler didn't use in its own code).  This
	    is a big change where typographical errors are likely
	    and would be a disaster.  Also add a detailed comment
	    of why not to re-apply change #2 no matter how good an
	    idea it may seem to be.

	2.  Re-assemble and verify that the executable didn't change.

	3.  Now fix the incorrect opcode.  There's a place in the
	    source code to change it now.

	4.  Re-assemble.  Verify that only one byte changed.  Verify
	    that the sample source code assembles correctly.  Just for
	    thoroughness, assemble the test file that includes all
	    opcodes and make sure nothing else changed.

	5.  Update the master source archive with the new version
	    and inform everyone who might have a private copy to
	    update it.  (No source code control systems then on
	    desktop floppy-disk computers, and I don't think the
	    Model II even had a hard disk (8 megabytes.  no, not
	    RAM or cache, hard disk space.) yet.)

The only way you would have detected this with using two different
assemblers to build the one of interest would be if one of the
assemblers you picked had the value of an opcode wrong.  Also, as
features were added, probably the only assembler that could assemble
the source code of interest was the assembler of interest anyway.
Z80 assemblers weren't nearly as standardized as C.

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

#108171

On 14/04/2017 21:17, supercat wrote:

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

Reflections on Trusting Trust
https://dl.acm.org/citation.cfm?id=1283940&CFID=751525768&CFTOKEN=11767401

Countering "Trusting Trust" through Diverse Double-Compiling
http://www.acsa-admin.org/countering-trusting-trust-through-diverse-double-compiling/

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

#108175

On Sunday, April 16, 2017 at 4:04:44 AM UTC-5, Noob wrote:
> On 14/04/2017 21:17, supercat wrote:
> 
> > 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.
> 
> Reflections on Trusting Trust
> https://dl.acm.org/citation.cfm?id=1283940&CFID=751525768&CFTOKEN=11767401
> 
> Countering "Trusting Trust" through Diverse Double-Compiling
> http://www.acsa-admin.org/countering-trusting-trust-through-diverse-double-compiling/

I hadn't thought about the problems of floating-point constants mentioned
in the latter paper, though those could be mitigated if one chose a compiler
which performed all of its internal math using integer types no longer than
32 bits (so as to allow bootstrapping via systems and compilers that are as
old as practical) and was designed to make the output be dependent solely
upon the source and configuration options.  If one of the first-stage
implementations is a lightweight 1990s compiler running on a 1990s computer,
it would be exceptionally unlikely that it could hide anything malicious
because there would be no "room" for such a thing.

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

#108355

Noob <root@127.0.0.1> wrote:

> On 14/04/2017 21:17, supercat wrote:
> 
> > 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.
> 
> Reflections on Trusting Trust
> https://dl.acm.org/citation.cfm?id=1283940&CFID=751525768&CFTOKEN=11767401
> 
> Countering "Trusting Trust" through Diverse Double-Compiling
> http://www.acsa-admin.org/countering-trusting-trust-through-diverse-double-compiling/

Double compiling... amateurs.

_Cross_-compile, then compile an interpreter for another language, in
that interpreter run a compiler for your own in-house language, in that
write a new compiler for the original language, and only then
cross-compile back.
Good luck getting a back door through GCC on Linux, Inform, Nu-Bazic,
TinyC on MacOS 9, back to GCC.

Richard

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

#108283

gazelle@shell.xmission.com (Kenny McCormack) writes:

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

There are certainly people who do care -- see

https://wiki.debian.org/ReproducibleBuilds

to learn more.

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

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

#108204

MehdiAmini <atorrses@gmail.com> writes:
[...]
> 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?

Can you explain clearly why you're using the -Wdate-time option in the
first place?

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

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

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

csiph-web