Re: OT: Requesting C advice

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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:
> [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.
>  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
> 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:
>  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.
> 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

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.              -
-                                                                    -
-      "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              -

[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux