[Bug libfortran/37707] Namelist read of array of derived type incorrect

["burnus at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1932 bytes --]



------- Comment #22 from burnus at gcc dot gnu dot org  2008-10-19 09:44 -------
(In reply to comment #19)
> > Warning: CHARACTER expression at (1) is being truncated (222/200)
> Tobias, you are right - the string is too short - 250 characters should do,
> however, and I get the same error.
> How did you provoke the warning (I certainly do not get it by default) ...

Well, actually I saw it when I compiled the program with NAG f95
("Initialisation expression for L truncated") which shows this message by
default. gfortran shows it with -Wcharacter-truncation or with -Wall (which I
used). [Contrary to NAG f95, gfortran shows the warning not only for
initialization expressions.]

(In reply to comment #21)
> Toon and Tobias:  Please try this attached patch.

Looks OK.

> The only thing I need to determine now is if there is a legacy behaviour we
> may want to deal with

Sunf95 and ifort seem to read -- without quotes -- all alphanumerical
characters plus e.g. § until the next space/comma (and they treat %"'$
special-> ignore, end of string/namelist or as error). With NAG f95, g95,
openf95, pathf95 and pgf95 one gets always an error message without quotes.

With gfortran-4.3 "str=test /" does not work but "str=test,/" does.

I think the patch by itself is OK but doing the same as ifort and sunf95 would
be also OK.

Interesting that this did not come up as issue before. Seemingly no one uses
write(...,namelist) with characters (as almost all compiler get this wrong) and
seemingly reading a list of characters is also not widely done.


@@ -1453,7 +1453,7 @@ namelist_write (st_parameter_dt *dtp)
       break;

     default:
-      dtp->u.p.nml_delim = '\0';
+      dtp->u.p.nml_delim = '"';

wouldn't it be easier/faster to simply remove the whole switch and use simply
  dtp->u.p.nml_delim = '"';
without special cases for the current delim status?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707