[comp.lang.c] Primos portability report

g-rh@cca.CCA.COM (Richard Harter) (02/17/88)

Here is a gotcha for C programs which will be ported to PRIMOS.

#include <stdio.h>
...
FILE *ifptr = stdin;
...
main(...) {....}

breaks BIND, which crashes with the approximate message
"IOBUF_: Attempt to reference undefined common."

The cure is to initialize FILE pointers with assignment statements, e.g.

#include <stdio.h>
....
FILE *ifptr;
main(...) { ifptr = stdin;....}

I haven't tested it on SEG.

Also, as far as I know, C programs should be compiled using the -oldfortran
option.

-- 

In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
	Richard Harter, SMDS  Inc.

blarson@skat.usc.edu (Bob Larson) (02/19/88)

In article <24599@cca.CCA.COM> g-rh@CCA.CCA.COM.UUCP (Richard Harter) writes:
>Here is a gotcha for C programs which will be ported to PRIMOS.
>#include <stdio.h>
>FILE *ifptr = stdin;
>main(...) {....}
>breaks BIND, which crashes with the approximate message
>"IOBUF_: Attempt to reference undefined common."

I've run into this problem before.  std(in,out) cannout be assigned to
FILE * variables other than in main.  (Yes, I consider this a major bug.
Unfortunatly, prime doesn't always agree with me.)

>I haven't tested it on SEG.
Same problem, differnt eror message.  I havn't found a GOOD (no mod to
program source) workaround.

>Also, as far as I know, C programs should be compiled using the -oldfortran
>option.

Huh what?  Always use -newfortran or -32ix unless you have code
specificly writen for the old meathod of calling "fortran" (other
language) procedures.  (If you do have such code, I recomend fixing
it.) -32ix is a big win in some cases.

Ps: for those of you interested, note the info-prime mailing list address
below.
--
Bob Larson	Arpa: Blarson@Ecla.Usc.Edu	blarson@skat.usc.edu
Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson
Prime mailing list:	info-prime-request%fns1@ecla.usc.edu
			oberon!fns1!info-prime-request

gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/19/88)

In article <7048@oberon.USC.EDU> blarson@skat.usc.edu (Bob Larson) writes:
>>FILE *ifptr = stdin;
>I've run into this problem before.  std(in,out) cannout be assigned to
>FILE * variables other than in main.

A more fundamental problem is that in some implementations stdin etc.
are not constant-expression macros, but more general rvalue macros,
so they cannot be used as static initializers.

g-rh@cca.CCA.COM (Richard Harter) (02/20/88)

In article <7048@oberon.USC.EDU> blarson@skat.usc.edu (Bob Larson) writes:
>
>>Also, as far as I know, C programs should be compiled using the -oldfortran
>>option.
>
>Huh what?  Always use -newfortran or -32ix unless you have code
>specificly writen for the old meathod of calling "fortran" (other
>language) procedures.  (If you do have such code, I recomend fixing
>it.) -32ix is a big win in some cases.

	I don't have all that much information.  However the genesis of
the remark is this.  We have a ~40,000 line program which we maintain
across several operating systems (primos, vms, flavors of unix).  The
original development environment is UNIX; ports are done to the other
operating systems.  About once a year we do a major port from unix to
primos.  When we did a port in late 1986 we hit the need for -oldfortran.

	The problem is not (on the surface) a problem with calls to other
language procedures, since these are not used.  However we do use a
minimum set of library routines (read, write, open, access, fopen,
fprint, close, fclose, malloc, free).  My understanding is that the 
library routines conceal calls to system utilities.  The problem may
involve passing literals as arguments (I am told that there was a problem
with this at one time.)

	In any case, the effect was that the program got confused about
returning from routines and produced the usual infinitely helpful primos
error messages.  All problems went away when we recompiled everything
with the -oldfortran option.  Mind you, this is not a straightforward
matter of fixing code -- everything is lint free and all calls to system
utilities appear to follow the manual.  It may be that there was a problem
with the C run time library that is now fixed.  However our situation is
that -oldfortan works; -newfortran didn't work a year ago; and there is
no obvious reason why.  We haven't checked to see if the problem is still
there.
-- 

In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
	Richard Harter, SMDS  Inc.