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.