PetscPrintf/ifort 9.1

[Barry Smith]

  Actually after thinking about this for a few minutes I realized my
mistake in logic. Since I cannot make PETSc exactly right and general
I will be bring down the server in a few minutes and start deleting 
all the PETSc files.

   Barry


On Wed, 29 Aug 2007, Barry Smith wrote:

> 
>   Leif,
> 
>     You obviously have thought about this more then me; I wasn't even 
> considering supporting \\, etc. So yes, it could generate unexpected results.
> 
>     Since I cannot do it exactly right and general I will simply remove
> PetscPrintf() and friends from PETSc for Fortran.
> 
>    Barry
> 
> 
> On Wed, 29 Aug 2007, Leif Strand wrote:
> 
> > Barry Smith wrote:
> > > On Wed, 29 Aug 2007, Leif Strand wrote:
> > > > (consider "\\n")
> > 
> > >    Actually this is not a problem, as was pointed out before the C compiler
> > > replaces the \n with a single charactor (ASCII 10) so my simple search and
> > > replace will never see the STRING "\n" when the Fortran compiler is gfortran
> > > so nothing will be done twice.
> > 
> > Again, consider "\\n".  With PetscFixSlashN(), you are trying to meet the
> > expectations of C programmers.  So, let's say I write the C-ish quasi-Fortran
> > code, 'call PetscPrintf("\\no")'.  As a C programmer, I might expect this to
> > print:
> > 
> > \no
> > 
> > [Of course, if I had plenty of coffee this morning, I would know I was calling
> > 'PetscPrintf' from Fortran, and therefore, I would not know what to expect in
> > this case, but we've already covered that.]
> > 
> > Intel's ifort will leave "\\n" as "\\n", so PetscFixSlashN() will see "\\n" at
> > runtime.  As of right now, PetscFixSlashN() code doesn't handle "\\"
> > correctly, so it will munge it so that it becomes {'\\', '\n', 'o'} and will
> > PETSc print
> > 
> > \
> > o
> > 
> > which is not what I intended.
> > 
> > If you beef-up PetscFixSlashN() so that it handles escaped-backslashes ("\\"),
> > you've "fixed" the 'ifort' case, but G95 is still broken.  G95 will translate
> > "\\no" to "\no" itself, at compile-time.  So PetscFixSlashN() will see "\no"
> > at runtime, and behave as if I had written "\no" in my code:
> > 
> > [LF]
> > o
> > 
> > At runtime, you have no way of knowing whether the user's Fortran compiler did
> > "\x" translation at compile-time, so you would need a 'configure.py' test to
> > check this -- and even then, PETSc would screw up in non-trivial cases (what
> > if the string was generated?).
> > 
> > Better to do nothing than to have a half-baked implementation which satisfies
> > users' faulty expectations.
> > 
> > --Leif
> > 
> > 
>