Re: #include optimization

From: Michael Wojcik (mwojcik_at_newsguy.com)
Date: 10/01/04 

Date: 1 Oct 2004 18:59:32 GMT

In article <2s2033F1bi389U1@uni-berlin.de>, Peter van Merkerk <merkerk@deadspam.com> writes:
>
> Even if binary compare shows that there are differences all may be well
> too. I learned this the hard way; compiling the same code twice with a
> certain compiler yielded different binaries. Apparently the compiler
> wrote the build date or something like that into the binary.

All it takes is one reference to __DATE__ or __TIME__.

I have projects where many of the TUs explicitly include build
timestamps using __DATE__ and __TIME__, since that information can be
useful in identifying precisely which build is being used. (Yes, the
projects also have explicit version information, and the modules have
version information that's updated automatically by the SCM system,
but it doesn't hurt to have confirmation.)

With that sort of project, binary comparison is basically useless.
Chuck's method certainly can work in some projects, but for something
the size that the OP is describing I suspect you'd spend a great deal
of time investigating false positives. 

-- 
Michael Wojcik                  michael.wojcik@microfocus.com
You brung in them two expert birdwatchers ... sayin' it was to keep us from
makin' dern fools of ourselfs ... whereas it's the inherent right of all to
make dern fools of theirselfs ... it ain't a right held by you official types
alone.   -- Walt Kelly

Relevant Pages

  • Re: #include optimization
    ... The source files have an ... Do a binary compare against the original object file. ... certain compiler yielded different binaries. ...
    (comp.lang.c)
  • Re: #include optimization
    ... The source files have an ... Do a binary compare against the original object file. ... certain compiler yielded different binaries. ...
    (comp.lang.cpp)