PetscPrintf/ifort 9.1

[Barry Smith]

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