Re: [TUHS] MacOS X is Unix (tm)

On Tue, Jan 3, 2017 at 1:04 PM, Joerg Schilling &lt;schily(a)schily.net&gt; wrote: DEC's Tru64 for Alpha defaulted to LP64 (ex-DECie, Tru64 hacker et al). You could get ILP64 with compiler switches, but Tru64 was the first of the LP64 systems. We chaired the 64 bit team between the vendors and ISV etc, but I'll not drag that dirt here. As I like to point out, the greatest gift DEC had to the industry was their 64 bit (LP64) DEC C and C++​ compiler, after 3-5 years before SGI, Sun et al. (much of that work lives today as the Intel compiler BTW). As a result the ISV had to make their code clean. When Sun, IBM et al followed suite a few years later, that had better code to work with***. Besides the Gimpel Flexelint <http://www.gimpel.com/html/flex.htm> (a very cool program and I recommend it highly for serious programmers in the key of what Larry has been discussing); Judy Ward's incredible diagnostics in the DEC C++ front-end was the only tool that I know of that really told you what was going on in your code (funny, I literally am typing this message after I just returned from lunch with her today, and we we talking about what we had to do in those days to help people). Since, I've taken on the topic in Quora so I'll not overly repeat myself here - there in more detail in that post. But it really comes down to the this: early (v7 and before) C code assumed sizeof(int) == sizeof(*int). When the Vax was introduced, it was just easier to go ILP32 when moving code from the old compilers and in the case of the Vax that made sense but was not always true. I personally built an early 68000 compiler that was LP32 and the MIT guys did it ILP32 in their compiler. I had no tools like we would have later, so porting code to the 68000 could >>sometimes<< be an issue. The MIT compiler (or its children) became the standard C compiler for most of the 68000 code [we both were "right" depending on your design preference - speed of port vs speed of execution]. When we did Alpha, we had >>long discussions<< about word size. It was agreed that LPxx was not reasonably safe (and that proved to be true). The problem was that -1 @ 64bits is not 0xFFFFFFFF and those sorts of errors Today, I think many of those error have been found, and the fact that most Intel*64 compilers use LP64 also and code pretty much works is a tribute to that work. That said, when we start using a 128bit int, I'm sure "dirty" code will appear. If I recall, the Gimpel guys will warning you when you have a bit mask. *** Picking on a Sun and the Sun ISV's here a little. I love to tell the stories (<-- plural) of ISV's that found their bugs rate on Solaris drop after the Tru64 port; because we forced them to clean up their act some. The Sun compiler would accept most anything and generate code, and as Larry says, much of the resultant code was garbage. While I can write crappy program in any language, a compiler with excellent warnings or tools like Flexelint, will not rid you of structural stuff, it will at least make what it written unambiguous and thus less likely to take a surprising nose dive in the field.