🚀 go-pugleaf

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