Given that “ASSERT(i == 10);” is out of the scope of “for (size_t I;
{}”, the ASSERT will only compile if “i” is defined within the scope that
ASSERT exists. If it does compile, the setting of “i” has nothing to do
with the count within the for-loop. Methinks thou didst mean:
size_t I;
for(i = 0; i < 10; i++)
{
// blah blah
}
ASSERT(i == 10);
But, mostly this is personal philosophy. Setting an inline trap to catch
the failing side in an ASSERT simply insures that condition is properly
handled. Not setting an inline time means you are absolutely, positively
sure the failing condition will never ever happen in release code. It’s
simply a matter of how thoroughly you think you need to cover your ass.
Gary G. Little
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Edouard A.
Sent: Wednesday, April 26, 2006 1:01 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] problem
Our philosophy of ASSERT usage is different, it’s more “It’s not an assert
if it may happen”. For example :
for(size_t i = 0; i < 10; i++)
{
// blah blah
}
ASSERT(i == 10);
To me, an assertion is something that should always be true, and if it’s
not
the case, something very wrong happened: either you have a bug to fix in
your or the system is going in total panic or the universe constant
changed.
I do not consider an unexpected situation to be an assertion fault, if it
is, I remove the assertion and add the appropriate handling code.
–
Edouard
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Tuesday, April 25, 2006 20:57
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] problem
Assertion failure warns developer about unexpected situation
and following code still handles it. Quite correct solution
for kernel code, IMO. I usually write such a code like this
(even in user mode):
if (!TVERIFY(condition)) {
// handle unexpected scenario
}
TVERIFY is ASSERT(condition) in checked build and (condition)
in free build. ASSERT macro has to expand as an boolean
expression for this purpose and I believe the latest DDKs
have it like this.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
> ----------
> From:
xxxxx@lists.osr.com[SMTP:xxxxx@lis
ts.osr.com] on behalf of Edouard > A.[SMTP:xxxxx@wanadoo.fr]
> Reply To: Windows System Software Devs Interest List
> Sent: Tuesday, April 25, 2006 8:39 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] problem
>
> Is it me or the assert is contradicted by the if statement under??
>
> –
>
> Edouard
>
>
> ________________________________
>
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of amitr0
> Sent: Tuesday, April 25, 2006 12:56
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] problem
>
>
> A P,
>
> Here is something from the microsoft sources. FatInit.C
inside IFS
> kit. Line # 408
>
>
> KeyValueInformation = (PKEY_VALUE_FULL_INFORMATION)Buffer;
>
> while (1) {
>
> Status = ZwQueryValueKey(Handle,
> ValueName,
> KeyValueFullInformation,
> KeyValueInformation,
> RequestLength,
> &ResultLength);
>
> ASSERT( Status != STATUS_BUFFER_OVERFLOW );
>
> if (Status == STATUS_BUFFER_OVERFLOW) {
>
> //
> // Try to get a buffer big enough.
> //
>
> if (KeyValueInformation !=
> (PKEY_VALUE_FULL_INFORMATION)Buffer) {
>
> ExFreePool(KeyValueInformation);
> }
>
> RequestLength += 256;
>
> KeyValueInformation = (PKEY_VALUE_FULL_INFORMATION)
>
ExAllocatePoolWithTag(PagedPool,
>
> RequestLength,
> ’ taF’);
>
> if (!KeyValueInformation) {
> return STATUS_NO_MEMORY;
> }
>
> } else {
>
> break;
> }
> }
>
>
>
>
>
>
>
> Well, if M$ does it this way, so can you. Well experts,
can’t we?
>
> — Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 To unsubscribe,
visit the
> List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
Wanadoo vous informe que cet e-mail a ete controle par
l’anti-virus mail.
Aucun virus connu a ce jour par nos services n’a ete detecte.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
