> ----------
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Maxim S. Shatskih[SMTP:xxxxx@storagecraft.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, April 27, 2006 11:31 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] problem
>It is known bug/feature in the VS compilers. for ( int i = 0;…) defines i
for the rest
>of function.
This is C++ standard (at least according to Stroustrup/Ellis). I used this in
Borland C++ 3.1 in around 1993.
From Breaking Changes in the Visual C++ 2005 Compiler (http://msdn2.microsoft.com/en-us/library/ms177253(vs.80).aspx):
/Zc:forScope now on by default
This is Standard C++ behavior; code that depends on the use of a variable declared in a for loop after the for loop scope has ended will now fail to compile. Use /Zc:forScope- to revert to the old, non-standard behavior. This change was introduced to create conformant code by default.
About assertions. In practice, they are not so good.
Usually, if the assertion fails, BSOD will follow very soon, and BSOD analyzis
will be enough to fix the bug.
It depends on the way how to use assertions. You’re right only if you asserts fatal problems only.
Now note that assertions are only to help bug analyzing, they do not make the
system more robust - they make BSOD anyway, just earlier.
Again, it depends. I use asserts as an early warning about conditions I beleive it’s important to know about when I write code. Later during development some of them can be changed or removed. No problem if code is written to assert and still fail gracefully. This way I’m able to debug most of the code with no debugger; just asserts and traces.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
Maxim S. Shatskih wrote:
>It is known bug/feature in the VS compilers. for ( int i = 0;…) defines i
>
>
>for the restof function.
>
>
This is C++ standard (at least according to Stroustrup/Ellis). I used this in
Borland C++ 3.1 in around 1993.
Stroustrup’s original C++ and the early draft standard had the “for”
variables live in the surrounding scope, so this worked:
for( int i = 0; i < 3; i++ )
{
}
printf( “%d\n”, i );
However, this was changed rather early in the standardization process,
so that the variables now live in the scope of the block controlled by
the “for” statement. Thus, the above is a syntax error in ISO standard
C++, because “i” is undefined after the closing bracket.
VC6 went feature-complete before the standard was finalized, so they
used the old interpretation. VC7 had a compiler switch, but chose the
old way as the default (a bad choice, in my opinion). VC8 defaults to
the standard scoping.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I would claim that it depends more on the character of the error
condition that you have discovered than it does on the “importance” of
the driver in question.
Even the beep driver should probably bugcheck if it truly thinks that it
has detected a heap corruption (whatever the source), because
effectively that is the same as finding a critical error in that
filesystem driver.
By the same token, the filesystem driver should not bugcheck if it
detects something like the samba bug that Raymond Chen has been talking
about recently in his blog (it’s a true error, albeit on someone else’s
machine, but it will only show the user incomplete directory
information, not cause any data corruption on an actual open file).
Michal Vodicka wrote:
> Now, clearly, what you see is a function of where you sit. So I’m sure my opinion (and that of the other posters here) is colored by the type of drivers I tend to work on (most of which, I admit, tend to be critical to system operation). Still…
>
I’d agree. If my USB driver fails for some reason, user won’t be able to use our fingerprint sensor. In the worst case it means user won’t be able to logon again or open encrypted data storage. Nothing of this excuses immediate BSOD and loss of big Word file which user just writes. On the other hand, if the problem is detected by a driver which controls filesystem to which Word just tries to write the data, situation is a bit different.
Still I believe 95% of drivers aren’t important enough to crash OS.
BTW, from developer’s point of view it is surely better to bugcheck and let user to submit crash to OCA. Better until pissed off users find you 
(I love when checked build USB OS drivers bugcheck just because I disconnect USB flashdrive…)
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
–
Ray