On Wed, 2007-05-30 at 14:31 -0500, Mike McCarty wrote: > Rick Stevens wrote: > > On Sat, 2007-05-26 at 08:03 -0500, Chris Schumann wrote: > > > >>Late reply; sorry. > >> > >> > >>>Date: Thu, 24 May 2007 08:43:26 -0700 > >>>From: Les <hlhowell@xxxxxxxxxxx> > >> > > [snip] > > >>Having used C since the original K&R version, I have to ask WHAT?!? > >> > >>Since when is C a virtual machine language? > > > > > > Having been on the ANSI C committee back in the day, Chris is correct. > > C was NEVER a "virtual machine language" system. That was left to > > But the Standard uses the term "abstract machine", which may be > what he intended. > > > Nicklas Wirth's team with the old UCSD P-System Pascal language and its > > derivatives (such as Modula 2). > > Those interested in historical matters might look here: > > http://cm.bell-labs.com/cm/cs/who/dmr/chist.html > > [snip] > > >>(and because it is a virtual machine language...) > >> > >>> That is why even the 8 bit implementations of C used a 16 bit > >>>integer. > >> > >>No it's not. They used 16 bit integers because you can't do much > >>of anything useful with only 8 bit integers. The compiler designers > >>for those systems (like the Apple II) had to work around the 8 bit > >>registers. Looking at the assembly-language source for some of the > >>libraries was not pleasant. > > > > Actually, that was a huge bone of contention in the committee meetings. > > The 16-bit integer was the "native" size of the registers on the machine > > that C was developed on (the PDP-11), so it sorta stuck. However, the > > standard makes absolutely no guarantees on how big an "int" is. It is > > completely up to the implementer of the compiler as to how big an "int" > > is (or a "char" is or an "unsigned long long" is...that's why the > > "sizeof" operator exists). > > This is incorrect. An integer must be able to represent at least > numbers in the range -32767 to 32767 inclusive. > > [QUOTE MODE ON] > > 5.2.4.2.1 Sizes of integer types <limits.h> > [#1] The values given below shall be replaced by constant > expressions suitable for use in #if preprocessing > directives. Moreover, except for CHAR_BIT and MB_LEN_MAX, > the following shall be replaced by expressions that have the > same type as would an expression that is an object of the > corresponding type converted according to the integer > promotions. Their implementation-defined values shall be > equal or greater in magnitude (absolute value) to those > shown, with the same sign. > .... > > -- minimum value for an object of type int > INT_MIN -32767 > > -- maximum value for an object of type int > INT_MAX +32767 > > [QUOTE MODE OFF] > > Since the Standard also requires a pure binary representation, > this means that an int is at least 16 bits. I haven't looked at the standard in probably 15 years. I got off the committee before the standard was approved (got tired of paying to go to the bloody meetings when the company I worked for balked at it). > > There is also no guarantee as to what a "null" is, other than no > > legitimate object will ever have a "null" address. I know of one system > > where the null address is all ones. The compiler knows that '\0' should > > be converted to the all ones format as well as when the word "null" > > should be, too. > > I have used a system which had three values for the null address > 0x0000 (in a certain mode only), 0x00000000, and 0x80000000. However, > it must compare equal to an unsigned integer of the correct size when > the integer has all bits off. Correct. The compiler knows what "null" means in various contexts, but it by no way means "all zeroes". > > P.J. Plaugher (founder of Whitesmiths') and the committee secretary had > > a great way of putting it: "An int is not a char and it's not a long, > > but will be the same as one or the other at various times in your > > career." > > > > As far as the libraries are concerned, the initial draft of what was in > > the standard C library made the library so damned big that it wouldn't > > fit in the standard process memory footprint of a VAX at the time. > > Care to substantiate that? As far as the Standard is concerned, it does > not address packaging issues. I'm talking about the very, very early days of discussing just what goes in the libraries--and indeed how many libraries there were going to be. The working document we had put almost everything in a single library. When we implemented it as a test case on the two most common systems we had (a PDP-11 and a VAX), the linker couldn't handle the library size. Indeed, without segmenting the program and using overlays, the famous "hello world" program couldn't fit on a VAX. Overlays worked, but it was spectacularly slow. > > That's when it got split up into the standard library, the "math" > > library, the "double precision" library and several others. > > This has nothing to do with Standard C. It is a packaging matter, > which the Standard does not address. For example, consider this > language from the Standard: > > [QUOTE MODE ON] > > 5.2.4.2.2 Characteristics of floating types <float.h> > > .... > > [#4] The accuracy of the floating-point operations (+, -, *, > /) and of the library functions in <math.h> and <complex.h> > that return floating-point results is implementation > defined. The implementation may state that the accuracy is > unknown. > > [QUOTE MODE OFF] > > IOW, it addresses where the prototypes exist, but not where the > object code exists or how it gets into your program (if, indeed, > it ever does, most of my programs wind up using a shared library). Again, I've not looked at the standard in years. I'm simply relating what went on in the ANSI committee behind the scenes for the two years I was involved. What the standard has is a distillation of all that went on before. Yes, things are in there that we sweated blood over and in some cases, I don't agree with. As to what's an "implementation" and what was part of the language per se got blurred over many, many times. "Should we define that math operations of similar precedence be evaluated right-to-left, left-to- right, or leave it up to the implementation?" "In a construct such as '&ptr->object', which is more tightly bound, the '->' or the '&'?" "Do we mandate an RPN-style calculation, algebraic or leave it up to the implemtation?" "Should we implement a multi-level 'break' statement or provide a 'goto' and statement labels?" All of that sort of thing went on, with some stuff defined by the standard and some left to implementation. As I said, I wasn't there at the end. The money was an issue, but also many of the meetings simply degenerated into finger-pointing sessions. As Charles Shultz once stated in "Peanuts": "Beneath the calm exterior lurk the dynamics of a nursery school recess." All in all, C is a great language, but it does have warts. It's a giraffe...a horse designed by a committee. > > Once the concept of splitting up libraries came up, lots of splits > > were proposed: string handling was going to be in a separate library, > > network stuff, file management, you name it. Some people actually did > > implement separate libraries, as the famous Sun network library split > > shows. ---------------------------------------------------------------------- - Rick Stevens, Principal Engineer rstevens@xxxxxxxxxxxx - - VitalStream, Inc. http://www.vitalstream.com - - - - "Microsoft is a cross between The Borg and the Ferengi. - - Unfortunately they use Borg to do their marketing and Ferengi to - - do their programming." -- Simon Slavin - ----------------------------------------------------------------------
