In message <Pine.LNX.3.96.991219120041.3816A-100000@guild.net>, Lord Isildur wr
ites:
>Not according to Dennis: "..A pointer to one type may be converted to a
>pointer to another type. The resulting pointer may cause addressing
>exceptions upon use if the subject pointer does not refer to an object
>suitably aligned in storage." 
>The only caveat here is alignment, obviously reflecting the PDP111/VAX11
>origins. 

However, the resulting object may be invalid; in C89, this is called
"indeterminately valued", in C9X, it's been made more clear as a "possible
trap representation".

Note that this is all completely orthogonal to the question of whether or not
there's additional data in a pointer.  *converted* allows for the possibility
that the new pointer and the old pointer, even though they refer to the "same"
location, *have different representations*.  One could be bigger than another,
for instance.

>and just who goes about deciding how to 'change' a language???

An ISO standards committee.  Which, for the record, appears to have Dennis's
blessing to adapt the language based on requirements that didn't exist on the
original PDP and VAX systems.  ;-)

>who declared it a 'standard' and how do they go about doing that? eh? 

ISO.

>don't people see how absolutely ridiculous it is to just up and announce
>that all of a sudden the language that is C is no longer C? 

That's why we number 'em.

Languages grow and change.  If you want to go back to a language with no void
pointers, no prototypes, and no standard library, you're welcome to.  :)

>My arguments about linear address spaces stem from a: that [effectively]
>this is the situation in all machines that run NetBSD and are hence the
>scope of this list, and b: that machines which don't possess somethign
>that can be treated as a linear address space are not particularly
>becoming as the targets of C compilers.

Even if the address space is linear, you can have additional information about
types and bounds in pointers, and this is a useful thing to do.  Code should
not break these rules without a *VERY* good reason.

It's fine by me if architecture-specific kernel code makes a few assumptions.
;-)

>languages that have all that overhead! C is beautiful for its simplicity! 
>I wont even get into the argument about the standard C library. 
>Are 'they' trying to make C into C++ or something? Can't they leave well
>enough alone? if they have such a burning desire to make languages, why
>dont they just make new languages instead of destroying old ones? 

Mostly because there are certain tasks that the compiler vendor can always do
a better job of than a programmer, because the vendor has a lot more
information.

Not that I'm a big fan of the vast and unwieldy floating-point stuff.  On
the other hand, the new standard provides a lot of very useful notational
conveniences.

I'd recommend waiting until you have a copy before you comment.  Read the
rationale, too - it explains why these changes were made.  We're not *totally*
irrational.

-s