I have no problem with this convention. However, I just checked the C standard,<br>and on page 254, in the stddef.h section, it says<br><br>  NULL is an implementation specific null pointer constant.<br><br>So technically, it does not have to be 0.<br>
<br>   Matt<br><br><div class="gmail_quote">On Wed, Jan 14, 2009 at 4:00 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
On Jan 14, 2009, at 3:37 PM, Satish Balay wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
There are tonnes of places in PETSc with this usage [which I guess is<br>
fixable].<br>
<br>
</blockquote>
   I have already pushed to petsc-3.0.0 the fixes for this. Virtually all were Matt's<br>
fault in strange parts of the code no body uses so they don't matter and then in<br>
the VecSetValues_ code.<br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
But imposing coding guidelines [which are unenforceable] to hide<br>
compiler differences is a bad policy..<br>
</blockquote>
<br>
     This has nothing to do with compiler differences; just because some Fortran<br>
compilers use the bit pattern of 1 for .true. and some use -1 does not change<br>
the fact that a PetscTruth value of 0 is false while any other value is true.<br>
<br>
  Using integers as boolean on the Fortran side is a perversity that had to be<br>
fixed.<br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
It will continue to waste<br>
time..<br>
</blockquote>
<br>
  In C the test if (something) and if (!something) means in the first case<br>
if the value of something is NOT 0 and the second means the value of something<br>
is 0. Hence, since C does not have a boolean value traditionally people have<br>
taken true to be any nonzero value and false to be the zero value. In fact,<br>
if you stick any nonzero value into a Fortran boolean it will treat it as true;<br>
so Fortran also follows this paradigm. It is just when .true. is used, the bit string<br>
of 1 or -1 is put in.<br>
<br>
  I don't know where the == PETSC_TRUE nonsense came from, it could be<br>
my fault. But the coding standard has been there for many years and most<br>
== PETSC_TRUE stuff was removed years ago.<br>
<br>
<br>
  Barry<br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
Satish<br>
<br>
On Wed, 14 Jan 2009, Barry Smith wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
 From the PETSc developers guide<br>
<br>
Do not use {\em if (rank == 0)} or {\em if (v == PETSC\_NULL)} or {\em if (flg<br>
== PETSC\_TRUE)} or {\em if (flg == PETSC\_FALSE)}<br>
instead use {\em if (!rank)} or {\em if (!v)} or {\em if (flg)} or {\em if<br>
(!flg)}.<br>
<br>
There was a flag == PETSC_TRUE in PETSc 3.0.0 that wasted a lot of several<br>
peoples time finding it. Come on folks, we have better things to do with our<br>
time. Please avoid this incorrect usage.<br>
<br>
 Barry<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote></div><br><br clear="all"><br>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener<br>