avoiding incorrect code

Matthew Knepley knepley at gmail.com
Wed Jan 14 16:07:25 CST 2009


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 <bsmith at mcs.anl.gov> 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: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20090114/b3e9c75b/attachment.html>


More information about the petsc-dev mailing list