PetscPrintf/ifort 9.1

[Barry Smith]

On Wed, 29 Aug 2007, Leif Strand wrote:

> IMHO, PETSc's behavior was correct before.  I.e., it was correct to do nothing
> -- it was correct to simply print the string the user passed-in, with no
> translation.  To do otherwise, PETSc would need a 'configure.py' test which
> checks to see whether the user's Fortran compiler already performs the "\n" ->
> LF translation at compile time (as G95 does), so that the translation doesn't
> get performed twice (consider "\\n")... it just gets messy.  Better to do
> nothing.

   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.

   Barry


> 
> The only thing slightly fishy about "achar(10)" is that it does assume that
> PetscPrintf is implemented in C (see below).
> 
> 
> Stephan Kramer wrote:
> > While this may work for you, it is certainly not *the* correct way to do it.
> > achar(10) corresponds to LF, whereas windows systems
> > expect CR+LF (i.e. achar(13)//achar(10)), it may still work under windows as
> > well though, depends on your terminal/ application
> > you view the output with. The correct way in C is really to use \n (and in
> > the above case I guess), and in fortran to use two
> > separate write statements.
> 
> It is fishy (as I said), but since PetscPrintf is implemented in C and
> ultimately calls vfprintf(), the correct thing will happen on all platforms.
> E.g., with VC++, the MSVCRT.DLL runtime will translate LF to CR,LF if the
> underlying "FILE" was opened in text mode.
> 
> It is portable, because a C/C++ implementation has no choice but to do
> linefeed translation this way (i.e., at runtime).  Consider:
> 
>     #include <stdio.h>
>     #include <string.h>
> 
>     int main()
>     {
>         char buffer[42];
>         strcpy(buffer, "Hello,\nworld.");
>         printf("%d %d\n", strlen(buffer), buffer[6]);
>         puts(buffer);
>         return 0;
>     }
> 
> This program will print
> 
> 13 10
> Hello,
> world.
> 
> on all platforms (even Windows).  (Note that the string has length 13, not 14:
> "\n" -> LF happened at compile time.)
> 
> To summarize: A C/C++ compiler translates "\n" to LF at compile time (this
> transformation is applied to string literals).  Therefore LF->CR+LF
> translation must happen at runtime on Windows (and it will happen even if the
> string came from Fortran code).  What a Fortran compiler does with strings is
> implementation-dependent.  G95 mimics what a C/C++ compiler would do by
> translating "\n" -> LF in string literals, but this is not standard Fortran.
> 
> --Leif
> 
>