simon@uunet.uu.net (Simon Pigot) (03/19/91)
Severe problems occur when using fortran 1.4 beta with C code generated
using yacc. It seems that fortran 1.4 beta uses a yacc parser to parse
fortran format specifications. Unfortunately the symbols used by their
yacc parser conflict with those of any local yacc parsers called - the
result is total confusion during formatted i/o including spurious error
messages most often reflecting format statements which have been mangled
because of the clash.
eg: This program has a C main which uses a yacc parser, at one stage it
calls a fortran program which happens to do some formatted internal i/o.
The following error message results because of clashes between the f77
1.4 compiler fortran format yacc parser and the local yacc parser.
ifio: [100] error in format
lately: writing sequential formatted internal IO
part of last format: (I5)
part of last string: |
Proof:
If you use nm(1) on libF77.so.1.4 you can see the yacc symbols and
entrypoints the compiler wants to use:
0005c9f0 D _yyact
00000004 C _yychar
0005cfb8 D _yychk
00000004 C _yydebug
0005d128 D _yydef
00000004 C _yyerrflag
00042f90 T _yyerror
0005c990 D _yyexca
00042934 T _yylex
00000004 C _yylval
00000004 C _yynerrs
0005cbd0 D _yypact
00041ac0 T _yyparse
0005cd40 D _yypgo
0005ea04 b _yyps
0005ea00 b _yypv
0005cd70 D _yyr1
0005ce94 D _yyr2
0005e9fc b _yys
0005ea08 b _yystate
0005ea0c b _yytmp
0005e9f8 b _yyv
00000004 C _yyval
Some of the yacc parser data structures are statics but others are
not..... Some of these are entrypoints (yyparse, yylex and yyerror) and
get confused with the local yacc parser entrypoints.....
I hope the sun fortran people fix this before the final 1.4 release.
Simon Pigot, (spigot@esri.com)
Environmental Systems Research Institute,
380 New York Street,
Redlands, Ca. 92373 Phone: (714) 793-2853 ext. 1479bill@stuart.stat.washington.edu (03/23/91)
In article <1931@brchh104.bnr.ca> esri!atlas!simon@uunet.uu.net (Simon Pigot) writes: >Severe problems occur when using fortran 1.4 beta with C code generated >using yacc. It seems that fortran 1.4 beta uses a yacc parser to parse >fortran format specifications. Unfortunately the symbols used by their >yacc parser conflict with those of any local yacc parsers called - the >result is total confusion during formatted i/o including spurious error >messages most often reflecting format statements which have been mangled >because of the clash. >If you use nm(1) on libF77.so.1.4 you can see the yacc symbols and >entrypoints the compiler wants to use: > ... > 00042f90 T _yyerror > 0005c990 D _yyexca > 00042934 T _yylex > ... >Some of the yacc parser data structures are statics but others are >not..... Some of these are entrypoints (yyparse, yylex and yyerror) and >get confused with the local yacc parser entrypoints..... There are too many global symbols defined in the newer Sun fortran libraries that have names that a C programmer expects to be able to use. This has caused me a lot of headaches. You can make a list of the offenders with cd /usr/lang/SC0.0 nm libF77.a | grep ' [TDC] ' | grep -v '_$' | awk '{print $3}' | sort | uniq There are 337 of them in Fortran 1.3. Only one contains the digit 7 (you might think they could flag them all with an F77_ prefix -- and document that convention). The list includes symbols corresponding to the C names "new", "scale", "subout", "tmpdir", "tab", "radix", "eor", "new", "rfill", "bufsiz", "cursor", "errflag", "fatal", as well as all the standard "yy.*" names generated by yacc. It is pretty easy to run into one of them when you mix C and Fortran code. >I hope the sun fortran people fix this before the final 1.4 release. ditto Bill
martelli@cadlab.sublink.org (Alex Martelli) (03/28/91)
esri!atlas!simon@uunet.uu.net (Simon Pigot) writes:
:Severe problems occur when using fortran 1.4 beta with C code generated
:using yacc. It seems that fortran 1.4 beta uses a yacc parser to parse
:fortran format specifications. Unfortunately the symbols used by their
:yacc parser conflict with those of any local yacc parsers called - the
:result is total confusion during formatted i/o including spurious error
Yes, I have met the same bug in the production release of 1.3 (by linking
with Ingres, which *also* had the same egregious oversight!). Sun support
quickly reproduced and acknowledged the bug, and I had a patch tape in
hand in a few days. As a temporary workaround, in the meantime, I had
used a copy of the library, patched with Perl (...do NOT trust any normal
text-oriented tool, such as sed, to patch a binary file... but Perl's
fine).
I share your hope that Sun realizes the true severity of this minor bug...
true, the usual case of user-written yacc code can be worked around easily
enough, but patching vendor-supplied binaries is not to everybody's
taste... besides the waste of time and energy in finding out what's
happening in the first place!
Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 53, Bologna, Italia
Email: (work:) martelli@cadlab.sublink.org, (home:) alex@am.sublink.org
Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434;
Fax: ++39 (51) 366964 (work only), Fidonet: 332/401.3 (home only).