lkml.org 
[lkml]   [2005]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] spi
On Tue, Aug 09, 2005 at 10:54:34AM -0700, Andy Isaacson wrote:
> On Mon, Aug 08, 2005 at 10:47:21AM -0700, Marc Singer wrote:
> > On Mon, Aug 08, 2005 at 07:35:36PM +0200, Marcel Holtmann wrote:
> > > > > + if (NULL == dev || NULL == driver) {
> > > >
> > > > Put the variable on the left side, gcc will complain if you incorrectly
> > > > put a "=" instead of a "==" here, which is all that you are defending
> > > > against with this style.
> > >
> > > I think in this case the preferred way is
> > >
> > > if (!dev || !driver) {
> > >
> >
> > That's not a guaranteed equivalence in the C standard. Null pointers
> > may not be zero. I don't think we have any targets that work this
> > way, however there is nothing wrong with explicitly testing for NULL.
>
> False. The expression "!x" is precisely equivalent to "x==0", no
> matter what the type of x is. [1] And furthermore, NULL==0. [2]
> Ergo, "NULL == dev" and "!dev" are defined to be equivalent.
>
> What you're confused about is that the *representation* of a null
> pointer constant does not necessarily have to be all-bits-zero. That
> is, the following code fragment might print something on a
> standard-compliant C implementation:

No, I'm not confused about the representation of a NULL. Keep in mind
that telling someone what they do or don't
understand/believe/think/feel is the fast track to being flamed.

>
> void *a = 0; unsigned char *p = (unsigned char *)&a;
> int i;
> for(i=0; i<sizeof(a); i++)
> if(p[i] != 0) printf("p[%d] = %02x!\n", i, p[i]);
>
> That does not change the fact that the source-code fragment "NULL" is
> defined to be equivalent to the source-code fragment "0". Simply the
> compiler must do whatever trickery necessary to ensure the correct
> values get generated in the object code for my above hypothetical
> architecture when I say "void *a = 0;".
>
> This is very similar to how floating point is handled in the abstract
> machine definition of the standard. Consider a weird FP implementation
> where 0.0 has a not-all-bits-zero representation, and change 'a' in my
> example above to type 'double'. Just because 0.0 is stored as the bit
> pattern 0x8000000000000000 does not mean that I have to write something
> other than "double a = 0;"!
>
> And furthermore, all of this was well-understood in the C89 standard;
> it's not new in the C99 standard, although there are some
> clarifications.
>
> [1] ISO/IEC 9899:1999 6.5.3.3 Unary arithmetic operators
>
> (5) The result of the logical negation operator ! is 0 if the value of
> its operand compares unequal to 0, 1 if the value of its operand
> compares equal to 0. The result has type int. The expression !E is
> equivalent to (0==E).
>
> [2] ISO/IEC 9899:1999 7.17
>
> The following types and macros are defined in the standard header
> <stddef.h>. ...
> NULL
> which expands to an implementation-defined null pointer constant...
>
> and 6.3.2.3 Pointers
> (3) An integer constant expression with the value 0, or such an
> expression cast to type void *, is called a null pointer constant.

It was explained to me that the !pointer test wasn't guaranteed to be
equivalent because of the way that the test is handled. The spec
fragments above don't address how the boolean test is coerced. Does
it cast pointer to an integer and perform the test, or does it cast
the 0 to a pointer and perform the test. The C++ spec I have is vague
on this point. The only reference it makes to pointers is that the
operand for ! may be a pointer.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-08-09 21:07    [W:0.176 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site