avoiding incorrect code
Interesting I didn't know this. So now even anal people can use if (!ptr) Thanks. Barry On Jan 14, 2009, at 5:28 PM, Jed Brown wrote: > On Wed, Jan 14, 2009 at 13:56, Barry Smith wrote: >> All of this demonstrates that it would be legal that that (!ptr) is >> not >> correct and one should always use if (ptr == NULL). > > FWIW, C99, 6.5.3.3.5 reads > > | 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). > > In (0 == ptr) the 0 is a null pointer constant (as per 6.5.9.2 `one > operand is a pointer and the other is a null pointer constant') so > there is no reason to prefer (ptr == NULL). Note that in C++, NULL is > a macro which expands to 0, not (void*)0 as is common in C, so that it > doesn't need an explicit cast. > > Jed
avoiding incorrect code
On Jan 14, 2009, at 4:07 PM, Matthew Knepley wrote:
> I have no problem with this convention. However, I just checked the
> C standard,
> and on page 254, in the stddef.h section, it says
>
> NULL is an implementation specific null pointer constant.
Yes this is correct, but there is more to it than that
C99 specs (aka ISO/IEC 9899:1999), This is what is says about null
pointers in 6.3.2.3.3 and 6.3.2.3.4:
3. An integer constant expression with the value 0, or such an
expression cast to type void *, is called a null pointer constant. If
a null pointer constant is converted to a pointer type, the resulting
pointer, called a null pointer, is guaranteed to compare unequal to a
pointer to any object or function.
4. Conversion of a null pointer to another pointer type yields a null
pointer of that type. Any two null pointers shall compare equal.
In other words if I do void *ptr = (void *) 0 then ptr is A null
pointer. Also if I do if (ptr == NULL) it is always true.
It is a little funky, the standard does not say that a null pointer
has to have a representation of all bits equal to zero. But it does
say that if I write (void*) 0 in my code the compiler MUST represent
it as a null pointer. The standard doesn't say that there has to be
only a SINGLE null pointer representation. It could be that NULL has a
different bit representation than (void*) 0 but the standard says that
that NULL == (void*) 0 has to return true.
This imposes enough constraints that no sane person would implement
NULL as anything but all zero bits, though it is allowed.
But I am still dancing around the issue. The issue is what does if (!
ptr) have to return; the standard doesn't seem to say anything about
this. In fact what does negation of a pointer mean? It could mean
negate each bit of the pointer, and return true if any of the bits is
1, but that is kind of a stupid definition. Any sane person would have
the compiler define if (!ptr) to mean if (ptr == NULL) in the same way
that if (!an_int) is defined as if (an_int == 0) Note that (!an_int)
does NOT mean negate each bit of an_int and return true if any bits
are nonzero.
All of this demonstrates that it would be legal that that (!ptr) is
not correct and one should always use if (ptr == NULL). On the other
hand no sane person would implement such a compiler because it would
make the system unneccesarily complicated and unnatural. In addition,
a huge percentage of C codes use if (!ptr) so even if someone did
implement this insane compiler most C code wouldn't even work properly.
Thus I submit that it is perfectly fine to use if (!ptr) in the PETSc
code. Stylistically I find (ptr == NULL) very ugly (why have a !
symbol if you don't use it?) and a sign that the programmer is trying
to show off his subtle knowledge of the C standard.
Barry
>
>
> So technically, it does not have to be 0.
>
>Matt
>
> On Wed, Jan 14, 2009 at 4:00 PM, Barry Smith
> wrote:
>
> On Jan 14, 2009, at 3:37 PM, Satish Balay wrote:
>
> There are tonnes of places in PETSc with this usage [which I guess is
> fixable].
>
> I have already pushed to petsc-3.0.0 the fixes for this. Virtually
> all were Matt's
> fault in strange parts of the code no body uses so they don't matter
> and then in
> the VecSetValues_ code.
>
>
> But imposing coding guidelines [which are unenforceable] to hide
> compiler differences is a bad policy..
>
> This has nothing to do with compiler differences; just because
> some Fortran
> compilers use the bit pattern of 1 for .true. and some use -1 does
> not change
> the fact that a PetscTruth value of 0 is false while any other value
> is true.
>
> Using integers as boolean on the Fortran side is a perversity that
> had to be
> fixed.
>
>
> It will continue to waste
> time..
>
> In C the test if (something) and if (!something) means in the first
> case
> if the value of something is NOT 0 and the second means the value of
> something
> is 0. Hence, since C does not have a boolean value traditionally
> people have
> taken true to be any nonzero value and false to be the zero value.
> In fact,
> if you stick any nonzero value into a Fortran boolean it will treat
> it as true;
> so Fortran also follows this paradigm. It is just when .true. is
> used, the bit string
> of 1 or -1 is put in.
>
> I don't know where the == PETSC_TRUE nonsense came from, it could be
> my fault. But the coding standard has been there for many years and
> most
> == PETSC_TRUE stuff was removed years ago.
>
>
> Barry
>
>
>
>
> Satish
>
> On Wed, 14 Jan 2009, Barry Smith wrote:
>
>
> From the PETSc developers guide
>
> Do not use {\em if (rank == 0)} or {\em if (v == PETSC\_NULL)} or
> {\em if (flg
> == PETSC\_TRUE)} or {\em if (flg == PETSC\_FALSE)}
> instead use {\em if (!rank)} or {\em if (!v)} or {\em if (flg)} or
> {\em if
> (!flg)}.
>
> There was a flag == PETSC_TRUE in PETSc 3
avoiding incorrect code
On Jan 14, 2009, at 4:11 PM, Satish Balay wrote: > On Wed, 14 Jan 2009, Barry Smith wrote: > >>> But imposing coding guidelines [which are unenforceable] to hide >>> compiler differences is a bad policy.. >> >>This has nothing to do with compiler differences; just because >> some Fortran compilers use the bit pattern of 1 for .true. and some >> use -1 does not change the fact that a PetscTruth value of 0 is >> false while any other value is true. > > Well our UserInterface [PETSC_TRUE,PETSC_FALSE] says one thing - but > now we are relying on a different UI [i.e only PETSC_FALSE is relavent > - PETSC_TRUE as currently defined is irrelavant - as everything else > other than PETSC_FALSE should be PETSC_TRUE] PETSC_TRUE is used when assigning a PetscTruth value the .true. value. Barry > > > I guess we can add in a python script to detect this uasage in code > [as we check for other things - doc related - in builddist anyway] > >> I don't know where the == PETSC_TRUE nonsense came from, it could be >> my fault. But the coding standard has been there for many years and >> most >> == PETSC_TRUE stuff was removed years ago. > > Well I added in the code which was user-contributed. But I could > verywell have done it - as I didn't remember this code guideline [and > the reason for it..] > > Satish >
avoiding incorrect code
On Wed, 14 Jan 2009, Barry Smith wrote: > > But imposing coding guidelines [which are unenforceable] to hide > > compiler differences is a bad policy.. > > This has nothing to do with compiler differences; just because > some Fortran compilers use the bit pattern of 1 for .true. and some > use -1 does not change the fact that a PetscTruth value of 0 is > false while any other value is true. Well our UserInterface [PETSC_TRUE,PETSC_FALSE] says one thing - but now we are relying on a different UI [i.e only PETSC_FALSE is relavent - PETSC_TRUE as currently defined is irrelavant - as everything else other than PETSC_FALSE should be PETSC_TRUE] I guess we can add in a python script to detect this uasage in code [as we check for other things - doc related - in builddist anyway] > I don't know where the == PETSC_TRUE nonsense came from, it could be > my fault. But the coding standard has been there for many years and most > == PETSC_TRUE stuff was removed years ago. Well I added in the code which was user-contributed. But I could verywell have done it - as I didn't remember this code guideline [and the reason for it..] Satish
avoiding incorrect code
I have no problem with this convention. However, I just checked the C
standard,
and on page 254, in the stddef.h section, it says
NULL is an implementation specific null pointer constant.
So technically, it does not have to be 0.
Matt
On Wed, Jan 14, 2009 at 4:00 PM, Barry Smith wrote:
>
> On Jan 14, 2009, at 3:37 PM, Satish Balay wrote:
>
> There are tonnes of places in PETSc with this usage [which I guess is
>> fixable].
>>
>>I have already pushed to petsc-3.0.0 the fixes for this. Virtually all
> were Matt's
> fault in strange parts of the code no body uses so they don't matter and
> then in
> the VecSetValues_ code.
>
>
> But imposing coding guidelines [which are unenforceable] to hide
>> compiler differences is a bad policy..
>>
>
> This has nothing to do with compiler differences; just because some
> Fortran
> compilers use the bit pattern of 1 for .true. and some use -1 does not
> change
> the fact that a PetscTruth value of 0 is false while any other value is
> true.
>
> Using integers as boolean on the Fortran side is a perversity that had to
> be
> fixed.
>
>
> It will continue to waste
>> time..
>>
>
> In C the test if (something) and if (!something) means in the first case
> if the value of something is NOT 0 and the second means the value of
> something
> is 0. Hence, since C does not have a boolean value traditionally people
> have
> taken true to be any nonzero value and false to be the zero value. In fact,
> if you stick any nonzero value into a Fortran boolean it will treat it as
> true;
> so Fortran also follows this paradigm. It is just when .true. is used, the
> bit string
> of 1 or -1 is put in.
>
> I don't know where the == PETSC_TRUE nonsense came from, it could be
> my fault. But the coding standard has been there for many years and most
> == PETSC_TRUE stuff was removed years ago.
>
>
> Barry
>
>
>
>>
>> Satish
>>
>> On Wed, 14 Jan 2009, Barry Smith wrote:
>>
>>
>>> From the PETSc developers guide
>>>
>>> Do not use {\em if (rank == 0)} or {\em if (v == PETSC\_NULL)} or {\em if
>>> (flg
>>> == PETSC\_TRUE)} or {\em if (flg == PETSC\_FALSE)}
>>> instead use {\em if (!rank)} or {\em if (!v)} or {\em if (flg)} or {\em
>>> if
>>> (!flg)}.
>>>
>>> There was a flag == PETSC_TRUE in PETSc 3.0.0 that wasted a lot of
>>> several
>>> peoples time finding it. Come on folks, we have better things to do with
>>> our
>>> time. Please avoid this incorrect usage.
>>>
>>> Barry
>>>
>>>
>>
>
--
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener
-- next part --
An HTML attachment was scrubbed...
URL:
avoiding incorrect code
On Jan 14, 2009, at 3:37 PM, Satish Balay wrote:
> There are tonnes of places in PETSc with this usage [which I guess is
> fixable].
>
I have already pushed to petsc-3.0.0 the fixes for this. Virtually
all were Matt's
fault in strange parts of the code no body uses so they don't matter
and then in
the VecSetValues_ code.
> But imposing coding guidelines [which are unenforceable] to hide
> compiler differences is a bad policy..
This has nothing to do with compiler differences; just because
some Fortran
compilers use the bit pattern of 1 for .true. and some use -1 does not
change
the fact that a PetscTruth value of 0 is false while any other value
is true.
Using integers as boolean on the Fortran side is a perversity that
had to be
fixed.
> It will continue to waste
> time..
In C the test if (something) and if (!something) means in the first
case
if the value of something is NOT 0 and the second means the value of
something
is 0. Hence, since C does not have a boolean value traditionally
people have
taken true to be any nonzero value and false to be the zero value. In
fact,
if you stick any nonzero value into a Fortran boolean it will treat it
as true;
so Fortran also follows this paradigm. It is just when .true. is used,
the bit string
of 1 or -1 is put in.
I don't know where the == PETSC_TRUE nonsense came from, it could be
my fault. But the coding standard has been there for many years and most
== PETSC_TRUE stuff was removed years ago.
Barry
>
>
> Satish
>
> On Wed, 14 Jan 2009, Barry Smith wrote:
>
>>
>> From the PETSc developers guide
>>
>> Do not use {\em if (rank == 0)} or {\em if (v == PETSC\_NULL)} or
>> {\em if (flg
>> == PETSC\_TRUE)} or {\em if (flg == PETSC\_FALSE)}
>> instead use {\em if (!rank)} or {\em if (!v)} or {\em if (flg)} or
>> {\em if
>> (!flg)}.
>>
>> There was a flag == PETSC_TRUE in PETSc 3.0.0 that wasted a lot of
>> several
>> peoples time finding it. Come on folks, we have better things to do
>> with our
>> time. Please avoid this incorrect usage.
>>
>> Barry
>>
>
avoiding incorrect code
On Jan 14, 2009, at 3:37 PM, Matthew Knepley wrote:
> On Wed, Jan 14, 2009 at 3:15 PM, Barry Smith
> wrote:
>
> From the PETSc developers guide
>
> Do not use {\em if (rank == 0)} or {\em if (v == PETSC\_NULL)} or
> {\em if (flg == PETSC\_TRUE)} or {\em if (flg == PETSC\_FALSE)}
> instead use {\em if (!rank)} or {\em if (!v)} or {\em if (flg)} or
> {\em if (!flg)}.
>
> There was a flag == PETSC_TRUE in PETSc 3.0.0 that wasted a lot of
> several peoples time finding it. Come on folks, we have better
> things to do with our time. Please avoid this incorrect usage.
>
> I am fine with 1 and 3. 4 should not matter, but I am somewhat
> worried about 2. I thought there was no guarantee that
> NULL was actually 0, so I always check NULL.
NOPE! The C standard specifically states that NULL is (void*)0.
thus checking == PETSC_NULL is not needed. if (!value) is good enough
and cleaner.
and yes 4 doesn't matter but is important to mirror the check of if
(flg) so someone doesn't do flg == PETSC_TRUE
Barry
>
>
> Matt
>
>
> Barry
> --
> What most experimenters take for granted before they begin their
> experiments is infinitely more interesting than any results to which
> their experiments lead.
> -- Norbert Wiener
avoiding incorrect code
There are tonnes of places in PETSc with this usage [which I guess is
fixable].
But imposing coding guidelines [which are unenforceable] to hide
compiler differences is a bad policy.. It will continue to waste
time..
Satish
On Wed, 14 Jan 2009, Barry Smith wrote:
>
> From the PETSc developers guide
>
> Do not use {\em if (rank == 0)} or {\em if (v == PETSC\_NULL)} or {\em if (flg
> == PETSC\_TRUE)} or {\em if (flg == PETSC\_FALSE)}
> instead use {\em if (!rank)} or {\em if (!v)} or {\em if (flg)} or {\em if
> (!flg)}.
>
> There was a flag == PETSC_TRUE in PETSc 3.0.0 that wasted a lot of several
> peoples time finding it. Come on folks, we have better things to do with our
> time. Please avoid this incorrect usage.
>
> Barry
>
avoiding incorrect code
On Wed, Jan 14, 2009 at 3:15 PM, Barry Smith wrote:
>
> From the PETSc developers guide
>
> Do not use {\em if (rank == 0)} or {\em if (v == PETSC\_NULL)} or {\em if
> (flg == PETSC\_TRUE)} or {\em if (flg == PETSC\_FALSE)}
> instead use {\em if (!rank)} or {\em if (!v)} or {\em if (flg)} or {\em if
> (!flg)}.
>
> There was a flag == PETSC_TRUE in PETSc 3.0.0 that wasted a lot of several
> peoples time finding it. Come on folks, we have better things to do with our
> time. Please avoid this incorrect usage.
I am fine with 1 and 3. 4 should not matter, but I am somewhat worried about
2. I thought there was no guarantee that
NULL was actually 0, so I always check NULL.
Matt
>
> Barry
>
--
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener
-- next part --
An HTML attachment was scrubbed...
URL:
avoiding incorrect code
From the PETSc developers guide
Do not use {\em if (rank == 0)} or {\em if (v == PETSC\_NULL)} or
{\em if (flg == PETSC\_TRUE)} or {\em if (flg == PETSC\_FALSE)}
instead use {\em if (!rank)} or {\em if (!v)} or {\em if (flg)} or
{\em if (!flg)}.
There was a flag == PETSC_TRUE in PETSc 3.0.0 that wasted a lot of
several peoples time finding it. Come on folks, we have better things
to do with our time. Please avoid this incorrect usage.
Barry
avoiding incorrect code
On Wed, Jan 14, 2009 at 13:56, Barry Smith wrote: > All of this demonstrates that it would be legal that that (!ptr) is not > correct and one should always use if (ptr == NULL). FWIW, C99, 6.5.3.3.5 reads | 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). In (0 == ptr) the 0 is a null pointer constant (as per 6.5.9.2 `one operand is a pointer and the other is a null pointer constant') so there is no reason to prefer (ptr == NULL). Note that in C++, NULL is a macro which expands to 0, not (void*)0 as is common in C, so that it doesn't need an explicit cast. Jed
