PetscPrintf/ifort 9.1

[Leif Strand]

Paul T. Bauman wrote:
> achar(10)

This is precisely the solution I was hoping someone would offer when I 
said I didn't know Fortran.  Fortran users should be expected to express 
things in Fortran :-)

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.

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