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.
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.
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.
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).
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.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
