avoiding incorrect code

[Barry Smith]

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
>>
>