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