How I wasted half a day.
UNDOCUMENTED FEATURE:
“/kernel /d1nodatetime”
WHY?
This interesting feature of VS2012 as the “WDK” breaks
ansi compatibility for the C/C++ compiler by removing the standard
predefined strings DATE , TIME , and TIMESTAMP.
Thanks. To whom do I send the bill?
Mark Roddy
I’d like to know the reasoning for removing these strings. Can’t imagine any.
Michal
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Tuesday, December 04, 2012 11:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] VS2012, yet another rant.
How I wasted half a day.
UNDOCUMENTED FEATURE:
“/kernel /d1nodatetime”
WHY?
This interesting feature of VS2012 as the “WDK” breaks ansi compatibility for the C/C++ compiler by removing the standard predefined strings DATE , TIME , and TIMESTAMP.
Thanks. To whom do I send the bill?
Mark Roddy
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately.
Thank You!
AuthenTec, Inc. http://www.authentec.com/
The TIME macro prevents a guarantee that each compilation of the same code yields the same outputs. This guarantee is valuable for build-speed, servicing, and legal reasons.
Nondeterminism is bad. Imagine two source files use TIME. If they happen to be compiled at the same second, they’ll wind up with the same string, so the identical strings will get coalesced into the .cdata section. But if one file is compiled a second later, the strings will be different, so will go into separate parts of the .cdata section. The presence of these extra 9 bytes of data will cause the linker to pack the cdata section differently, which might cause the entire section to round up to an another page, which causes other sections to move around. And then the code that references the data changes too – what might have been a near address could now be a far address, requiring a longer processor instruction, increasing the size of the routine. The larger function exceeds the optimizers limit for inlining, and the routine is no longer inlined, causing other routines to be restructured as register pressure decreases…
(In contrast, the timestamp in the PE header is not put into the instruction stream, so changes to its value don’t cause ripple effects all over the binary like TIME can.)
(The d1nodatetime flag is one example of the variety of ways in which the operating systems people at Microsoft have been trying to persuade the compiler people at Microsoft to make the compiler more deterministic. Another example: C++ “anonymous functions” and “anonymous namespaces” are not actually anonymous; the compiler assigns them a name internally. That naming algorithm used to be nondeterministic.)
Didn’t see this one. You want /kernel. As for nodatetime, it is off by default because you can’t create a serviceable binary when using these macros, you could change nothing in the code you get a diff binary. You can turn this off with the ui in the project properties
d
dent from pjone
From: Vodicka, Michalmailto:xxxxx
Sent: ?12/?4/?2012 3:15 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE: [ntdev] VS2012, yet another rant.
I?d like to know the reasoning for removing these strings. Can?t imagine any.
Michal
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Tuesday, December 04, 2012 11:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] VS2012, yet another rant.
How I wasted half a day.
UNDOCUMENTED FEATURE:
“/kernel /d1nodatetime”
WHY?
This interesting feature of VS2012 as the “WDK” breaks ansi compatibility for the C/C++ compiler by removing the standard predefined strings DATE , TIME , and TIMESTAMP.
Thanks. To whom do I send the bill?
Mark Roddy
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately.
AuthenTec, Inc. http://www.authentec.comhttp:</http:>
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer ??
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>
I’m confused here - does this mean that TIME will now break builds?
If we remove that switch, then all is well, correct?
Thanks,
Mm
On Dec 4, 2012 5:07 PM, “Jeffrey Tippet”
wrote:
> The TIME macro prevents a guarantee that each compilation of the same
> code yields the same outputs. This guarantee is valuable for build-speed,
> servicing, and legal reasons.
>
> Nondeterminism is bad. Imagine two source files use TIME. If they
> happen to be compiled at the same second, they’ll wind up with the same
> string, so the identical strings will get coalesced into the .cdata
> section. But if one file is compiled a second later, the strings will be
> different, so will go into separate parts of the .cdata section. The
> presence of these extra 9 bytes of data will cause the linker to pack the
> cdata section differently, which might cause the entire section to round up
> to an another page, which causes other sections to move around. And then
> the code that references the data changes too – what might have been a
> near address could now be a far address, requiring a longer processor
> instruction, increasing the size of the routine. The larger function
> exceeds the optimizers limit for inlining, and the routine is no longer
> inlined, causing other routines to be restructured as register pressure
> decreases…
>
> (In contrast, the timestamp in the PE header is not put into the
> instruction stream, so changes to its value don’t cause ripple effects all
> over the binary like TIME can.)
>
> (The d1nodatetime flag is one example of the variety of ways in which the
> operating systems people at Microsoft have been trying to persuade the
> compiler people at Microsoft to make the compiler more deterministic.
> Another example: C++ “anonymous functions” and “anonymous namespaces” are
> not actually anonymous; the compiler assigns them a name internally. That
> naming algorithm used to be nondeterministic.)
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
TIME won’t break your build. It would make it more difficult for you to ask “how did this change affect my code”, but you obviously understand the tradeoffs here.
It will break by default, there is a setting in the vcxproj that will allow it to continue to work
d
dent from pjone
From: Martin O’Brienmailto:xxxxx
Sent: ?12/?4/?2012 5:15 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE: [ntdev] VS2012, yet another rant.
I’m confused here - does this mean that TIME will now break builds?
If we remove that switch, then all is well, correct?
Thanks,
Mm
On Dec 4, 2012 5:07 PM, “Jeffrey Tippet” > wrote:
The TIME macro prevents a guarantee that each compilation of the same code yields the same outputs. This guarantee is valuable for build-speed, servicing, and legal reasons.
Nondeterminism is bad. Imagine two source files use TIME. If they happen to be compiled at the same second, they’ll wind up with the same string, so the identical strings will get coalesced into the .cdata section. But if one file is compiled a second later, the strings will be different, so will go into separate parts of the .cdata section. The presence of these extra 9 bytes of data will cause the linker to pack the cdata section differently, which might cause the entire section to round up to an another page, which causes other sections to move around. And then the code that references the data changes too – what might have been a near address could now be a far address, requiring a longer processor instruction, increasing the size of the routine. The larger function exceeds the optimizers limit for inlining, and the routine is no longer inlined, causing other routines to be restructured as register pressure decreases…
(In contrast, the timestamp in the PE header is not put into the instruction stream, so changes to its value don’t cause ripple effects all over the binary like TIME can.)
(The d1nodatetime flag is one example of the variety of ways in which the operating systems people at Microsoft have been trying to persuade the compiler people at Microsoft to make the compiler more deterministic. Another example: C++ “anonymous functions” and “anonymous namespaces” are not actually anonymous; the compiler assigns them a name internally. That naming algorithm used to be nondeterministic.)
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>
Still confused.
Say I have a logging macro that uses it, what will happen?
Thanks,
Mm
On Dec 4, 2012 5:26 PM, “Doron Holan” wrote:
> It will break by default, there is a setting in the vcxproj that will
> allow it to continue to work
>
> d
>
> dent from pjone
> ------------------------------
> From: Martin O’Brien
> Sent: 12/4/2012 5:15 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] VS2012, yet another rant.
>
> I’m confused here - does this mean that TIME will now break builds?
>
> If we remove that switch, then all is well, correct?
>
> Thanks,
>
> Mm
> On Dec 4, 2012 5:07 PM, “Jeffrey Tippet”
> wrote:
>
>> The TIME macro prevents a guarantee that each compilation of the same
>> code yields the same outputs. This guarantee is valuable for build-speed,
>> servicing, and legal reasons.
>>
>> Nondeterminism is bad. Imagine two source files use TIME. If they
>> happen to be compiled at the same second, they’ll wind up with the same
>> string, so the identical strings will get coalesced into the .cdata
>> section. But if one file is compiled a second later, the strings will be
>> different, so will go into separate parts of the .cdata section. The
>> presence of these extra 9 bytes of data will cause the linker to pack the
>> cdata section differently, which might cause the entire section to round up
>> to an another page, which causes other sections to move around. And then
>> the code that references the data changes too – what might have been a
>> near address could now be a far address, requiring a longer processor
>> instruction, increasing the size of the routine. The larger function
>> exceeds the optimizers limit for inlining, and the routine is no longer
>> inlined, causing other routines to be restructured as register pressure
>> decreases…
>>
>> (In contrast, the timestamp in the PE header is not put into the
>> instruction stream, so changes to its value don’t cause ripple effects all
>> over the binary like TIME can.)
>>
>> (The d1nodatetime flag is one example of the variety of ways in which the
>> operating systems people at Microsoft have been trying to persuade the
>> compiler people at Microsoft to make the compiler more deterministic.
>> Another example: C++ “anonymous functions” and “anonymous namespaces” are
>> not actually anonymous; the compiler assigns them a name internally. That
>> naming algorithm used to be nondeterministic.)
>>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Default: build fails
Go to.project and change setting: build works
d
dent from pjone
From: Martin O’Brienmailto:xxxxx
Sent: ?12/?4/?2012 6:01 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE: [ntdev] VS2012, yet another rant.
Still confused.
Say I have a logging macro that uses it, what will happen?
Thanks,
Mm
On Dec 4, 2012 5:26 PM, “Doron Holan” > wrote:
It will break by default, there is a setting in the vcxproj that will allow it to continue to work
d
dent from pjone
____________________________
From: Martin O’Brienmailto:xxxxx
Sent: 12/4/2012 5:15 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE: [ntdev] VS2012, yet another rant.
I’m confused here - does this mean that__TIME will now break builds?
If we remove that switch, then all is well, correct?
Thanks,
Mm
On Dec 4, 2012 5:07 PM, “Jeffrey Tippet” > wrote:
The TIME macro prevents a guarantee that each compilation of the same code yields the same outputs. This guarantee is valuable for build-speed, servicing, and legal reasons.
Nondeterminism is bad. Imagine two source files use TIME. If they happen to be compiled at the same second, they’ll wind up with the same string, so the identical strings will get coalesced into the .cdata section. But if one file is compiled a second later, the strings will be different, so will go into separate parts of the .cdata section. The presence of these extra 9 bytes of data will cause the linker to pack the cdata section differently, which might cause the entire section to round up to an another page, which causes other sections to move around. And then the code that references the data changes too – what might have been a near address could now be a far address, requiring a longer processor instruction, increasing the size of the routine. The larger function exceeds the optimizers limit for inlining, and the routine is no longer inlined, causing other routines to be restructured as register pressure decreases…
(In contrast, the timestamp in the PE header is not put into the instruction stream, so changes to its value don’t cause ripple effects all over the binary like__TIME can.)
(The d1nodatetime flag is one example of the variety of ways in which the operating systems people at Microsoft have been trying to persuade the compiler people at Microsoft to make the compiler more deterministic. Another example: C++ “anonymous functions” and “anonymous namespaces” are not actually anonymous; the compiler assigns them a name internally. That naming algorithm used to be nondeterministic.)
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>
Thanks, dude.
Mm
On Dec 4, 2012 6:21 PM, “Doron Holan” wrote:
> Default: build fails
> Go to.project and change setting: build works
>
> d
>
> dent from pjone
> ------------------------------
> From: Martin O’Brien
> Sent: 12/4/2012 6:01 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] VS2012, yet another rant.
>
> Still confused.
>
> Say I have a logging macro that uses it, what will happen?
>
> Thanks,
>
> Mm
> On Dec 4, 2012 5:26 PM, “Doron Holan” wrote:
>
>> It will break by default, there is a setting in the vcxproj that will
>> allow it to continue to work
>>
>> d
>>
>> dent from pjone
>> ------------------------------
>> From: Martin O’Brien
>> Sent: 12/4/2012 5:15 PM
>> To: Windows System Software Devs Interest List
>> Subject: RE: [ntdev] VS2012, yet another rant.
>>
>> I’m confused here - does this mean that TIME will now break builds?
>>
>> If we remove that switch, then all is well, correct?
>>
>> Thanks,
>>
>> Mm
>> On Dec 4, 2012 5:07 PM, “Jeffrey Tippet”
>> wrote:
>>
>>> The TIME macro prevents a guarantee that each compilation of the
>>> same code yields the same outputs. This guarantee is valuable for
>>> build-speed, servicing, and legal reasons.
>>>
>>> Nondeterminism is bad. Imagine two source files use TIME. If they
>>> happen to be compiled at the same second, they’ll wind up with the same
>>> string, so the identical strings will get coalesced into the .cdata
>>> section. But if one file is compiled a second later, the strings will be
>>> different, so will go into separate parts of the .cdata section. The
>>> presence of these extra 9 bytes of data will cause the linker to pack the
>>> cdata section differently, which might cause the entire section to round up
>>> to an another page, which causes other sections to move around. And then
>>> the code that references the data changes too – what might have been a
>>> near address could now be a far address, requiring a longer processor
>>> instruction, increasing the size of the routine. The larger function
>>> exceeds the optimizers limit for inlining, and the routine is no longer
>>> inlined, causing other routines to be restructured as register pressure
>>> decreases…
>>>
>>> (In contrast, the timestamp in the PE header is not put into the
>>> instruction stream, so changes to its value don’t cause ripple effects all
>>> over the binary like TIME can.)
>>>
>>> (The d1nodatetime flag is one example of the variety of ways in which
>>> the operating systems people at Microsoft have been trying to persuade the
>>> compiler people at Microsoft to make the compiler more deterministic.
>>> Another example: C++ “anonymous functions” and “anonymous namespaces” are
>>> not actually anonymous; the compiler assigns them a name internally. That
>>> naming algorithm used to be nondeterministic.)
>>>
>>>
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging
>> and other seminars visit: http://www.osr.com/seminars To unsubscribe,
>> visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
Nondeterminism is bad. Imagine two source files use TIME. If they
happen to be compiled at the same second, they’ll wind up with the same
string, so the identical strings will get coalesced into the .cdata section. But if
one file is compiled a second later, the strings will be different, so will go into
separate parts of the .cdata section. The presence of these extra 9 bytes of
data will cause the linker to pack the cdata section differently, which might
cause the entire section to round up to an another page, which causes other
sections to move around. And then the code that references the data
changes too – what might have been a near address could now be a far
address, requiring a longer processor instruction, increasing the size of the
routine. The larger function exceeds the optimizers limit for inlining, and the
routine is no longer inlined, causing other routines to be restructured as
register pressure decreases…
That doesn’t sound any different to any other change that you might make to your code though. The fact that you have a chance of getting a “fast” or “slow” build basically at random shouldn’t make any difference in terms of overall execution time, and if it does matter and 9 bytes is the difference between the two then you’re doing it wrong and it was going to break eventually anyway.
James
It is no different, but any code change is explicit and reproducible. Change to TIME is neither. And while Jeff’s scenario is a bit of an edge case, it has happened in the past and is a valid concern. There is no “doing it wrong”, rather it us being very careful and measuring these specific details when building and comparing build to build
d
dent from pjone
From: James Harpermailto:xxxxx
Sent: ?12/?4/?2012 8:05 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE: [ntdev] VS2012, yet another rant.
>
> Nondeterminism is bad. Imagine two source files use TIME. If they
> happen to be compiled at the same second, they’ll wind up with the same
> string, so the identical strings will get coalesced into the .cdata section. But if
> one file is compiled a second later, the strings will be different, so will go into
> separate parts of the .cdata section. The presence of these extra 9 bytes of
> data will cause the linker to pack the cdata section differently, which might
> cause the entire section to round up to an another page, which causes other
> sections to move around. And then the code that references the data
> changes too – what might have been a near address could now be a far
> address, requiring a longer processor instruction, increasing the size of the
> routine. The larger function exceeds the optimizers limit for inlining, and the
> routine is no longer inlined, causing other routines to be restructured as
> register pressure decreases…
>
That doesn’t sound any different to any other change that you might make to your code though. The fact that you have a chance of getting a “fast” or “slow” build basically at random shouldn’t make any difference in terms of overall execution time, and if it does matter and 9 bytes is the difference between the two then you’re doing it wrong and it was going to break eventually anyway.
James
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>
The issue is not "is it going to break [eventually or otherwise] as much
as “can we reproduce this behavior in a recent compilation?” Suppose the
recompilation creates a different packing of segments, as already
described. the biggest problem is not the sudden introduction of a
failing behavior as much as the sudden disappearance of one, making it
difficult or impossible to isolate the cause.
Back in the 1980s, we had a policy for developers that I put in place: if
someone gets a memory-damage bug, the configuration is frozen at that
point. No more checkins of code are permitted in that development branch.
This allowed the person searching for the bug to be able to reproduce it
at will (single-threaded code is highly deterministic) without, say, some
new-and-different allocation pattern to mask the bug (example: a dangling
pointer that now results in “damage” to freespace that does not corrupt
the allocator headers). And the priority was “if you see a storage-damage
bug, everything, including your current development path, STOPS until that
bug is found and fixed”.
Sometimes this worked entirely too well. I was the most “intuitive”
debugger of storage damage bugs, so after a day or so of thrashing about,
someone would say, “Let’s see what Joe can do” and the bug would land on
my desk. Mostly, I could find and fix it in under a day. Although there
was once a 72-hour marathon where two of us would hand the bug and a
status report to the other every ten hours or so. (Ultimately, it turned
out to be my bug, a <= when it should have been a <).
We had formalized this idea in our Hydra operating system, with a concept
known as a “blind process” that could not query date or time, the idea
being to be able to force bitwise-identical behavior. Unfortunately, we
couldn’t freeze the file system, so could not guarantee that the input
bits were identical; the problem in its general case became so intractable
that the feature was never implemented.
I was once presented a hand-calligraphed scroll, showing a fish (floundef)
spearing a giant cockroach, from one of the compiler groups for finding,
in 17 hours, a bug the team had worked on for a week. It was
seventh-level damage before it caused an actual failure.
For all the various rants about C++ coding, I have found that I get
essentially zero occurrences of storage damage bugs using C++.
But in this case, of disabling date/time macros, I am in complete
agreement with the decision. As in “been there, done that”.
joe
>
> Nondeterminism is bad. Imagine two source files use TIME. If they
> happen to be compiled at the same second, they’ll wind up with the same
> string, so the identical strings will get coalesced into the .cdata
> section. But if
> one file is compiled a second later, the strings will be different, so
> will go into
> separate parts of the .cdata section. The presence of these extra 9
> bytes of
> data will cause the linker to pack the cdata section differently, which
> might
> cause the entire section to round up to an another page, which causes
> other
> sections to move around. And then the code that references the data
> changes too – what might have been a near address could now be a far
> address, requiring a longer processor instruction, increasing the size
> of the
> routine. The larger function exceeds the optimizers limit for inlining,
> and the
> routine is no longer inlined, causing other routines to be restructured
> as
> register pressure decreases…
>That doesn’t sound any different to any other change that you might make
to your code though. The fact that you have a chance of getting a “fast”
or “slow” build basically at random shouldn’t make any difference in terms
of overall execution time, and if it does matter and 9 bytes is the
difference between the two then you’re doing it wrong and it was going to
break eventually anyway.James
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Although I haven’t built a driver in several years, I keep following this forum for its insight into programming issues.
I had never thought of this issue with DATE TIME but now it is explained it is obviously such a good idea to get rid of it.
I think I will change my code (user space and embedded) to avoid these in future, it is so obvious that a build from the same base should produce identical code and this might be an issue for me in a future debug scenario. It has been a problem anyway because, for example, a sign-on message may display a build time that is not the time of the last build, only of the module that contains the macro. This information probably should be supplied globally from a reference that may update automatically on each build during normal development but can be frozen when debugging or on release/archive.
It would be nice to see these issues being aired before they get embedded in tool releases though. Where would be a good forum to see and perhaps participate in these discussions?
Mike
----- Original Message -----
From: Jeffrey Tippet
To: Windows System Software Devs Interest List
Sent: Wednesday, December 05, 2012 1:05 AM
Subject: RE: [ntdev] VS2012, yet another rant.
The TIME macro prevents a guarantee that each compilation of the same code yields the same outputs. This guarantee is valuable for build-speed, servicing, and legal reasons.
Nondeterminism is bad. Imagine …
Um IT IS PART OF THE ANSI C/C++ STANDARD.
What other parts of the standard language would we like to jettison?
Perhaps we could form a committee to decide what should or should not be in
the language.
By the way I don’t think you get a byte for byte identity from two
different builds with or without TIME.
Mark Roddy
On Wed, Dec 5, 2012 at 4:20 AM, Mike Kemp wrote:
> **
> Although I haven’t built a driver in several years, I keep following this
> forum for its insight into programming issues.
>
> I had never thought of this issue with DATE TIME but now it is
> explained it is obviously such a good idea to get rid of it.
>
> I think I will change my code (user space and embedded) to avoid these in
> future, it is so obvious that a build from the same base should produce
> identical code and this might be an issue for me in a future debug
> scenario. It has been a problem anyway because, for example, a sign-on
> message may display a build time that is not the time of the last build,
> only of the module that contains the macro. This information probably
> should be supplied globally from a reference that may update automatically
> on each build during normal development but can be frozen when debugging or
> on release/archive.
>
> It would be nice to see these issues being aired before they get embedded
> in tool releases though. Where would be a good forum to see and perhaps
> participate in these discussions?
>
> Mike
>
>
> ----- Original Message -----
> From: Jeffrey Tippet
> To: Windows System Software Devs Interest List
> Sent: Wednesday, December 05, 2012 1:05 AM
> Subject: RE: [ntdev] VS2012, yet another rant.
>
> The TIME macro prevents a guarantee that each compilation of the same
> code yields the same outputs. This guarantee is valuable for build-speed,
> servicing, and legal reasons.
>
> Nondeterminism is bad. Imagine …
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
On 12/5/2012 9:02 AM, Mark Roddy wrote:
Um IT IS PART OF THE ANSI C/C++ STANDARD.
What other parts of the standard language would we like to jettison?
They didn’t jettison the TIME macro; they gave you the option to
ignore it. I find their explanation perfectly reasonable. The new
default will make it easier to detect unexpected code changes, which is
a good thing.
I have to agree with Mark on this one. Microsoft has been blasted many times throughout history (*back to the 1990’s) for being non-standard in its compilers. That’s how we got such abominations as BOOL or BOOLEAN instead of the standard boolean types.
Unless you are doing DO178, an exact binary comparison is ridiculous. Even the compile date/time in the object header will throw a binary compare off. There are far better ways to verify a source to object to source comparison than to create this abhorent standard violation.
Please Microsoft, move closer to complying with the standards in a timely manner as opposed to moving away from standards.
Greg
— xxxxx@hollistech.com wrote:
From: Mark Roddy
To: “Windows System Software Devs Interest List”
Subject: Re: [ntdev] VS2012, yet another rant.
Date: Wed, 5 Dec 2012 09:02:57 -0500
Um IT IS PART OF THE ANSI C/C++ STANDARD.
What other parts of the standard language would we like to jettison?
Perhaps we could form a committee to decide what should or should not be in
the language.
By the way I don’t think you get a byte for byte identity from two
different builds with or without TIME.
Mark Roddy
On Wed, Dec 5, 2012 at 4:20 AM, Mike Kemp wrote:
> **
> Although I haven’t built a driver in several years, I keep following this
> forum for its insight into programming issues.
>
> I had never thought of this issue with DATE TIME but now it is
> explained it is obviously such a good idea to get rid of it.
>
> I think I will change my code (user space and embedded) to avoid these in
> future, it is so obvious that a build from the same base should produce
> identical code and this might be an issue for me in a future debug
> scenario. It has been a problem anyway because, for example, a sign-on
> message may display a build time that is not the time of the last build,
> only of the module that contains the macro. This information probably
> should be supplied globally from a reference that may update automatically
> on each build during normal development but can be frozen when debugging or
> on release/archive.
>
> It would be nice to see these issues being aired before they get embedded
> in tool releases though. Where would be a good forum to see and perhaps
> participate in these discussions?
>
> Mike
>
>
> ----- Original Message -----
> From: Jeffrey Tippet
> To: Windows System Software Devs Interest List
> Sent: Wednesday, December 05, 2012 1:05 AM
> Subject: RE: [ntdev] VS2012, yet another rant.
>
> The TIME macro prevents a guarantee that each compilation of the same
> code yields the same outputs. This guarantee is valuable for build-speed,
> servicing, and legal reasons.
>
> Nondeterminism is bad. Imagine …
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Actually Mark has it right they did jettison the standard. The standard
indicates that removing items should require an action of the user (i.e.
the default is ANSI and you can have a switch to change something, which
is what the compiler did but not the WDK). Also, how does this make it
easier to detect unexpected code changes, the binary is still going to
be different, unless they have really broken things.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“George M. Garner Jr.” wrote in
message news:xxxxx@ntdev:
> On 12/5/2012 9:02 AM, Mark Roddy wrote:
> > Um IT IS PART OF THE ANSI C/C++ STANDARD.
> >
> > What other parts of the standard language would we like to jettison?
>
> They didn’t jettison the TIME macro; they gave you the option to
> ignore it. I find their explanation perfectly reasonable. The new
> default will make it easier to detect unexpected code changes, which is
> a good thing.
Don Burn wrote:
Also, how does this make it
easier to detect unexpected code changes, the binary is still going to
be different, unless they have really broken things.
Only the timestamp in the PE header will change, which the tools can
ignore. That’s the point.
Having said that, I am now in the habit of adding:
void SourceCppIdentify()
{
KdPrint(( "source.cpp built on " DATE " at " TIME “\n” ));
}
to every source file, then DriverEntry does:
KdPrint(( “This is the xxx driver\n” );
SourceCppIdentify();
FilterCppIdentify();
IoctlCppIdentify();
It’s a great help in answering nagging questions like “umm, did I
remember to copy the binary before I ran this test?”
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Only the timestamp in the PE header will change, which the tools can
> ignore. That’s the point.
>
> Having said that, I am now in the habit of adding:
> void SourceCppIdentify()
> {
> KdPrint(( “source.cpp built on " DATE” at " TIME"\n" ));
> }
…
> It’s a great help in answering nagging questions like “umm, did I
> remember to copy the binary before I ran this test?”
So one could just print the PE timestamp (getting it thru, er, a simple but
undocumented trick).
That will work even if you don’t recompile the .c file that contains
SourceCppIdentify.
– pa