bug-findutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On the use of 0 or NULL, the discussion continues...


From: Eric Blake
Subject: Re: On the use of 0 or NULL, the discussion continues...
Date: Tue, 26 Jun 2007 18:39:09 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.12) Gecko/20070509 Thunderbird/1.5.0.12 Mnenhy/0.7.5.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Bob Proulx on 6/26/2007 4:35 PM:
> The following is more typical.
> 
>   void *var1 = 0;
>   void *var2 = NULL;
>   printf("%p\n", var1);
>   printf("%p\n", var2);
> 
> In this case neither gcc nor g++ -O -Wall flag any errors or
> differences.

Because both var1 and var2 are already properly typed, there is no bug in
your counterexample.  Here's another example of code that works fine on
32-bit machines, but is a potential disaster on 64-bit, and for which gcc
3.4.4 on cygwin does not warn (newer gcc coupled with the correct
__attribute__-decorated headers can warn, but you cannot rely on that
being present on all developer's machines yet).

#include <unistd.h>
int main()
{
  return execl("ls", "Makefile", 0);
}


>  Here is another example.
> 
>   typedef struct var { int value; } var_t;
>   var_t *var1 = 0;
>   if (var1) { printf ("%d\n", var1->value); }
>   if (var1 != 0) { printf ("%d\n", var1->value); }
>   if (var1 != NULL) { printf ("%d\n", var1->value); }
> 
> Of these I prefer '(var1 != 0)' but also have used the simple '(var1)'
> with its implied '!= 0' often enough too.  But in the uses I normally
> see for NULL such as the above it does not provide additional type
> checking.  I welcome counter examples.

I prefer option 1, but will use option 3 when my company coding standards
require no implicit conversions to bool.  I personally don't like option
2, but this is so much of a bike shed color discussion that I tend to
ignore any differences between the three unless there is a consistency issue.

> 
> C++ is not C and the type rules are quite different there.  In C++
> void* cannot be automatically coerced into pointers of different types
> therefore NULL cannot be defined as (void*)0.  Typically in C++ NULL
> is defined to be 0.  Outside of g++ in other C++ compilers NULL really
> is the same as 0.  g++ uses an internal extension __null to provide
> for additional type checking but most other compilers do not.

Which is why C++0x is in the process of standardizing something very
similar to gcc's __null via the proposed new keyword nullptr:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2214.pdf

> 
> BTW... I don't feel the need to try to convince anyone.  If I did then
> we would have to move on to the one true brace style or more
> significantly whether the return from malloc() should be cast (the
> return of malloc() should never be cast in C) and so forth. :-)

Agreed.  And that's why the GNU Coding Standards intentionally leave some
matters of style unspecified.  :)

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGgbGt84KuGfSFAYARApYSAKCr+LeF4O1xZ9X+PJ7pQnGTFvnAVgCgjnss
iS2omAxoLv8HfvbRQdOUuqU=
=GPJm
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]