OT: Requesting C advice

[Mike McCarty]

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 at pacbell.net>
>>

[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!