Prev: Fortran in newly released JASON report
Next: template for module compilation
From: Bil Kleb on 25 Apr 2010 16:27
On 2010-04-25 16:15:02 -0400, Bil Kleb said:
> Sorry for the red herrings, I use -Wall and -warn options out of
> habit, I was not expecting them to warn me of runtime string
> truncation during a namelist read.

Although, gfortran's warning:

Warning: Unused variable 'nml_string' declared at (1)

does seem to be incorrect as nml_string is used during
the namelist read and write?

I was using the gfortran on my 10.6.2 Mac:

% gfortran --version | head -1
GNU Fortran (GCC) 4.4.2

Regards,
--
Bil Kleb

From: glen herrmannsfeldt on 25 Apr 2010 18:59
Bil Kleb <bil.kleb(a)nasa.gov> wrote:
(snip)

> Sorry for the red herrings, I use -Wall and -warn options out of
> habit, I was not expecting them to warn me of runtime string
> truncation during a namelist read.

>> Note that iostat does not even define a warning category. It has
>> end-of-file, end-of-record, and error categories, but no warnings.

> Again, perhaps I used the wrong terminology. The

> if (ios==0) write(*,*) 'Error: namelist ...'

> line is the "warning" I am seeking.

Sometimes there is a distinction between "error" (something
is definitely wrong) and "warning" (something might be wrong,
check carefully).

>> I don't know whether there exist any compilers that have the capability
>> to detect I/O string truncation like that (and possibly elevate it to an
>> error that could be returned as an iostat code).

Since truncation seems to be part of Fortran string assignment,
it isn't so obvious. It has been suggested that compilers give
a warning for the case:

str=str || 'xyz'

which truncates the concatenation down to str=str.

> IBM has an CNVERR= extension that seems to offer this

Normally conversion error comes from having characters in a
numeric field that aren't allowed. It isn't so obvious that
it should apply in this case.

> (see http://bit.ly/bZmKAr), but the standard apparently does
> not support this essential sort of diagnostics to make namelists
> useful?

It seems that it doesn't bother most people, though as far as
I know NAMELIST isn't all that popular. I presume list directed
input will also truncate quietly. I believe that it is normal for
the A format descriptor.

Note that most Fortran systems don't trap fixed point overflow,
such that

&NL I=999999999999999999999999, /

would likely not cause a warning, error, or other indication.
(I didn't test it, though.)

-- glen
From: Jim Xia on 25 Apr 2010 21:30
On Apr 25, 2:14 pm, Bil Kleb <bil.k...(a)nasa.gov> wrote:
> Hi,
>
> What am I missing?  I can't figure out how to have
> Fortran warn me that it has truncated a character
> string during a namelist read...
>
> % cat > nml_string_truncation.f90 <<EOF
> program nml_string_truncation
>
>   integer :: ios
>   character(35) :: nml_contents = "&NMLIST NML_STRING='123456789' /"
>   character(4)  :: nml_string
>   namelist /nmlist/ nml_string
>
>   write(*,*) nml_contents
>   open(7,file='example.nml') ; write(7,*) nml_contents ; rewind(7)
>   read(7,nml=nmlist,iostat=ios)
>   write(*,nml=nmlist)
>
>   if (ios==0) write(*,*) 'Error: namelist read did not detect string
> truncation'
>
> end program
> EOF
>
> % ifort -warn -check nml_string_truncation.f90 && ./a.out
>  &NMLIST NML_STRING='123456789' /
>  &NMLIST
>  NML_STRING      = 1234
>  /
>  Error: namelist read did not detect string truncation
>
> % g95 -Wall nml_string_truncation.f90 && ./a.out
>  &NMLIST NML_STRING='123456789' /
>  &NMLIST NML_STRING = '1234',
>  /
>  Error: namelist read did not detect string truncation
>
> % gfortran -Wall nml_string_truncation.f90 && ./a.out
> nml_string_truncation.f90:4.29:
>
>   character(4)  :: nml_string
>                              1
> Warning: Unused variable 'nml_string' declared at (1)
>  &NMLIST NML_STRING='123456789' /
> &NMLIST
>  NML_STRING="1234",
>  /
>  Error: namelist read did not detect string truncation
>
> TIA,
> --
> Bil Kleb



This isn't an error as standard clearly spilled out what the behavior
should be. I'm using N1826 so if you're using an older version of
standard, you'll find the same text but may be of different clause.
It's under "Namelist input values", the text has been there probably
since F90.

"Let len be the length of the next effective item, and let w be the
length of the character sequence. If len is less
than or equal to w, the leftmost len characters of the sequence are
transmitted to the next effective item. If len
is greater than w, the constant is transmitted to the leftmost w
characters of the next effective item and the
remaining len-w characters of the next effective item are filled with
blanks. The effect is as though the sequence
were assigned to the next effective item in an intrinsic assignment
statement (7.2.1.3)."

No one will give you an error message, including IBM, because this is
perfectly legal Fortran code.


Cheers,

Jim
From: Jim Xia on 25 Apr 2010 21:44
>
> Note that most Fortran systems don't trap fixed point overflow,
> such that
>
>  &NL I=999999999999999999999999, /
>
> would likely not cause a warning, error, or other indication.
> (I didn't test it, though.)



Shouldn't speak before testing it. This is what XLF tells you

"1525-096 A data item processed during an integer read is too large.
The program will recover by assigning the data item the value
2147483647."

I was using 4-byte integer to read your input, and the previous error
popped up at runtime.


Cheers,

Jim
First  |  Prev  | 
Pages: 1 2
Prev: Fortran in newly released JASON report
Next: template for module compilation