Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!jade!eris!mwm From: mwm@eris.UUCP Newsgroups: comp.sys.amiga Subject: Re: Portable "C" Code Message-ID: <3134@jade.BERKELEY.EDU> Date: Sat, 11-Apr-87 16:24:29 EST Article-I.D.: jade.3134 Posted: Sat Apr 11 16:24:29 1987 Date-Received: Sun, 12-Apr-87 19:49:12 EST References: <8704071939.AA09157@cory.Berkeley.EDU> <1102@rpics.RPI.EDU> <659@batcomputer.tn.cornell.edu> Sender: usenet@jade.BERKELEY.EDU Reply-To: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) Organization: Missionaria Phonibalonica Lines: 112 In article <659@batcomputer.tn.cornell.edu> hsgj@tcgould.tn.cornell.edu.UUCP (Dan Green) writes: >In article <1102@rpics.RPI.EDU> guilford@rpics.RPI.EDU (Jim Guilford) writes: >>I've read several articles dealing with the incompatibilities between >>lattice and manx C-compilers. This may be a naive question, but why is there >>such an incompatibility? Isn't the purpose of a High-Level-Language to avoid >>such problems. Foolish mortal! C is one of the most portable languages around, but given two compilers from differen vendors, I can almost certainly produce code that will compile with one and not the other. There's a good chance I can also produce code that compiles on both, and gives radically different results. ("Almost certainly" instead of "certainly" because most Unix vendors use PCC as a base. That makes things harder.) >I have never used Amiga Manx so this is written from a Lattice perspective. Ditto. However, I have worked with people with Manx compilers to produce code that will compile/run under both. >I think a lot of compatibliity problems are (aside from RKM calling >conventions) the difference in the "standard" stdio packages on both >compilers. Yup. The other problem is that Manx makes an "int" 16 bits and Lattice makes it 32 bits. Since "ints" is the default size for function parameters & return values, things that aren't int's in those places cause problems. This is the source of the "RKM calling conventions" problems. Lattice people tend not to cast things (I'm guilty of that - I use function prototypes, which serves the same purpose). With Manx, code that passes non-int's without saying what's going on tends to die horribly. If Manx supported function prototyping, this problem wouldn't be so nasty. With Lattice, code broken as above tends to work. Lattice, of course, support function prototyping. >I know that I just finished a routine that had to generate >-true- random numbers. On every 4.2BSD cc I have used (under vax750, >gould,sequent) the function is called "random()" and it returns an integer >from 0 to MAXINT. In Lattice C, a similar function is called "lrand48()" >and does the same thing but returns from 0 to MAXLONG. Why the name >change? Yes, but if I type "man lrand48" on my big Unix box (lynx), I get a man page (which is odd, because on lynx, sizeof(short) = sizeof(long) = sizeof(int) = 64 bits). The catch is that Lynx doesn't run a BSD-derived Unix. It runs a SysIII/V derived Unix. Note that there are probably more of those around then 4BSD systems. In other words, Lattice didn't change the name, they just used a different Unix than you did. [Side note: random() & like don't produce -true- random numbers. At best, they produce a nice long sequece of pseudo-randome numbers. Many vendor-supplied functions for doing so do so _very_ poorly. If you're serious about needing a good source of "random" numbers, apply statistical test to your PRN generator to see if it meets your needs. If it doesn't right your own. Knuth Vol. 2 is a good place to start looking.] >Lattice also didn't like the way some of the string routines >were named and called some funny names, like "stccpy" for "strcpy". Before >anyone flames, yes they do have a #define strcpy stccpy automatically so >you can still use strcpy. In this case, sysV doesn't differ from BSD. Don't know why Lattice did this. Since the "correct" names work, it doesn't matter. >Speaking of that, I believe someone said >that Manx has the "index" function, while Lattice uses "stptok" to >search for a substring. Wrong on two counts. First, index() doesn't search for substrings, it searches for characters in a string. strchr() is the Lattice (and SysIII/V) equivalent. BSD doesn't have a stptok() equivalent. Maybe something like this is responsible for the "stccpy" names (but I doubt it, as strcpy is explicitly mentioned as being in the library in K&R). >Who is standard? I don't know. There is no standard. The best that can be done is the dpANS (Draft Proposed American National Standard). Lattice is working on following that, and the results can be seen in 3.10. Notice that dpANS trys to stay with SysIII/V libraries. These are different from the BSD libraries, which Manx copied. Hopefully, in future releases, Manx will have routines with the dpANS names. >But anyways, if your code relies on a lot of these idiosyncratically >named functions, then it probably won't port. No, it probably won't compile & run if you copy it. You'll have to make some changes. But experienced C programmers should be able to handle all of this with no problem. Final comment: I'm not trying to start a compiler war. Unfortunately, Manx doesn't provide near the dpANS compatability that Lattice does. I consider dpANS to be a good thing, as it will increase the portability of C programs. Because of this, the above posting may sound like I'm saying bad things about Manx. I am, in that *I* consider lack of dpANS compatability to be a bad thing (sort of like lack of flexnames). However, that is not the only basis for judging compiler, and some very good people consider it to be totally irrelevant. You've got to consider your applications, and select a compiler based on that.