PetscPrintf/ifort 9.1

[Leif Strand]

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