Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

namelist read diagnositcs?

92 views
Skip to first unread message

Bil Kleb

unread,
Apr 25, 2010, 2:14:52 PM4/25/10
to
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

dpb

unread,
Apr 25, 2010, 2:43:50 PM4/25/10
to
Bil Kleb 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...
>
...

AFAIK there isn't any way just as an A or list-directed read will return
the maximum length of the input string or the limit of the CHARACTER
variable length to hold the input.

Only reading the record in a variable long enough to hold it and parsing
it will determine that there are more characters than space allocated to
hold them under Standard i/o operations afaiaa.

Some compilers have an option to scan ahead and return the remaining
number of characters in the input record ("Q" edit descriptor in
DEC/Compaq/Intel compilers, I don't know who else may have that or
something similar) but it is an extension, not Standard (albeit
occasionally quite useful).

--

Richard Maine

unread,
Apr 25, 2010, 2:52:26 PM4/25/10
to
Bil Kleb <bil....@nasa.gov> wrote:

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

Well most warnings are compilation-time things. In particular, that's so
for switches like the -Wall and -warn that you tried.

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

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). If so, it will probably
be some more particular switch than the general -Wall or -warn kinds of
things. I'm sure you won't find it on most compilers, but you might find
one somewhere. (If I had to guess a candidate, it might be IBM; I don't
know that they have such a thing, but I'd think them the best guess).

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

Richard Maine

unread,
Apr 25, 2010, 3:12:51 PM4/25/10
to
Richard Maine <nos...@see.signature> wrote:

> Bil Kleb <bil....@nasa.gov> wrote:
>
> > 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...
>
> Well most warnings are compilation-time things. In particular, that's so
> for switches like the -Wall and -warn that you tried.

...


> (If I had to guess a candidate, it might be IBM; I don't
> know that they have such a thing, but I'd think them the best guess).

I forgot to mention that, as it would be an I/O library kind of option,
you would more likely find it controlled by something like environment
variables instead of compiler switches. The reason I mentioned IBM is
because I recall that IBM at least used to (probably stilll does, but
its been a while since I used an IBM system) have environment variables
to control some I/O issues. I don't know if they have that particular
one, but I recall once running into an environment variable to control a
different I/O issue that had annoyed me. (The IBM system at the time was
by default "fixing up" errors such as illegal characters in numeric
input. That was when I first ran into the practical implications of the
set of I/O error conditions being compiler dependent. I later found that
at least there was an environment variable to fix what I regarded as the
obnoxious behavior. The default might also have subsequentky changed.)

Bil Kleb

unread,
Apr 25, 2010, 4:15:02 PM4/25/10
to
> Bil Kleb <bil....@nasa.gov> wrote:
>
>> 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...
>
> Well most warnings are compilation-time things. In particular, that's so
> for switches like the -Wall and -warn that you tried.

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.

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

IBM has an CNVERR= extension that seems to offer this
(see http://bit.ly/bZmKAr), but the standard apparently does
not support this essential sort of diagnostics to make namelists
useful?

Regards,
--
Bil Kleb

Bil Kleb

unread,
Apr 25, 2010, 4:27:03 PM4/25/10
to
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

glen herrmannsfeldt

unread,
Apr 25, 2010, 6:59:14 PM4/25/10
to
Bil Kleb <bil....@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

Jim Xia

unread,
Apr 25, 2010, 9:30:03 PM4/25/10
to

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

Jim Xia

unread,
Apr 25, 2010, 9:44:59 PM4/25/10
to
>
> 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

0 new messages