Re: ntdll/file.c: Fix a possible NULL dereferencing.

[Nikolay Sivov]

Markus Hitter wrote:
> if (!attr || !attr->ObjectName) return STATUS_INVALID_PARAMETER;
> Shouldn't this be splitted? It isn't safe to rely on evaluation order. 
> Or is it a default compiler setting for us?

ntdll/file.c: Fix a possible NULL dereferencing.

[Henri Verbeet]

2008/8/27 Nikolay Sivov <bunglehead(a)gmail.com>:
> Markus Hitter wrote:
> > if (!attr || !attr->ObjectName) return STATUS_INVALID_PARAMETER;
> > Shouldn't this be splitted? It isn't safe to rely on evaluation order.
> > Or is it a default compiler setting for us?

This is well defined in C. !attr will be evaluated first, and if it
evaluates to true, the rest of the condition won't be evaluated. This
is also known as short-circuit evaluation.

ntdll/file.c: Fix a possible NULL dereferencing.

[Nikolay Sivov]

Henri Verbeet wrote:
> 2008/8/27 Nikolay Sivov <bunglehead(a)gmail.com>:
> > Markus Hitter wrote:
> > > if (!attr || !attr->ObjectName) return STATUS_INVALID_PARAMETER;
> >
> > Shouldn't this be splitted? It isn't safe to rely on evaluation order.
> > Or is it a default compiler setting for us?
>
> This is well defined in C. !attr will be evaluated first, and if it
> evaluates to true, the rest of the condition won't be evaluated. This
> is also known as short-circuit evaluation.

I thought it's possible to override this: not a evaluation order of 
course but the completeness of
evaluation for debug purpose.

ntdll/file.c: Fix a possible NULL dereferencing.

[Rob Shearman]

2008/8/27 Nikolay Sivov <bunglehead(a)gmail.com>:
> Henri Verbeet wrote:
> > 2008/8/27 Nikolay Sivov <bunglehead(a)gmail.com>:
> > > Markus Hitter wrote:
> > > > if (!attr || !attr->ObjectName) return STATUS_INVALID_PARAMETER;
> > >
> > > Shouldn't this be splitted? It isn't safe to rely on evaluation order.
> > > Or is it a default compiler setting for us?
> >
> > This is well defined in C. !attr will be evaluated first, and if it
> > evaluates to true, the rest of the condition won't be evaluated. This
> > is also known as short-circuit evaluation.
>
> I thought it's possible to override this: not a evaluation order of
> course but the completeness of
> evaluation for debug purpose.

All C89/C99-compliant compilers will always respect the order of
evaluation of the operands of the logical AND and OR operators. I
don't know what "debug purpose" you are referring to, but the code
generated for "if (!attr || !attr->ObjectName)" is guaranteed by the C
standard to never crash on a NULL pointer.

-- 
Rob Shearman

ntdll/file.c: Fix a possible NULL dereferencing.

[Nikolay Sivov]

Rob Shearman wrote:
> 2008/8/27 Nikolay Sivov <bunglehead(a)gmail.com>:
> > Henri Verbeet wrote:
> > > 2008/8/27 Nikolay Sivov <bunglehead(a)gmail.com>:
> > > > Markus Hitter wrote:
> > > > > if (!attr || !attr->ObjectName) return STATUS_INVALID_PARAMETER;
> > > >
> > > > Shouldn't this be splitted? It isn't safe to rely on evaluation order.
> > > > Or is it a default compiler setting for us?
> > >
> > > This is well defined in C. !attr will be evaluated first, and if it
> > > evaluates to true, the rest of the condition won't be evaluated. This
> > > is also known as short-circuit evaluation.
> >
> > I thought it's possible to override this: not a evaluation order of
> > course but the completeness of
> > evaluation for debug purpose.
>
> All C89/C99-compliant compilers will always respect the order of
> evaluation of the operands of the logical AND and OR operators. I
> don't know what "debug purpose" you are referring to, but the code
> generated for "if (!attr || !attr->ObjectName)" is guaranteed by the C
> standard to never crash on a NULL pointer.

By "debug purpose" I meant this situation: if a second operand of OR 
operator is a return value
of a some call could I force it to be called regardless of first operand 
value for example to
get some debug output inside this call.

P.S. I was confused because some years ago using Delphi compiler I've 
found an option called
something like "complete boolean evaluation" or something like that.

In a C89 draft I've found just now:
"...If the first operand compares unequal to 0, the second operand is 
not evaluated..."
So this question is closed now.

ntdll/file.c: Fix a possible NULL dereferencing.

[Markus Hitter]

Am 27.08.2008 um 11:27 schrieb Nikolay Sivov:
> Markus Hitter wrote:
> > if (!attr || !attr->ObjectName) return STATUS_INVALID_PARAMETER;
> > Shouldn't this be splitted? It isn't safe to rely on evaluation order.
> > Or is it a default compiler setting for us?

You know, this isn't part of the patch and answering to a patch  
submission essentially means it won't be applied.

Thanks Gentlemen, my duties are done.


MarKus

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/