Incrementing after a cast

[Wayne Throop]

> .csnet"@relay.cs.net>
> Casts are conversions? Oh? You'd never know it looking at the code that
> out of my C compilers ... including Harbison's!  He just regards away.

Interesting.  I suppose then you'd conclude that "int" and "long" must
be the same type in C, since code generated by many pcc based compilers
includes no conversions for casts from one to the other?  Gad, what are
they teaching in schools that belong to the CSnet these days, anyhow?

> The fact that there are machines which would like to have C compilers on 
> which ((sometype *)p)++ doesn't work as a "regard as" only means that 
> these machines aren't compatible with a lot of people's notion of C's model 
> of computation. There's a whole lot more machines on which ((sometype *)p)++ 
> makes perfect legal, technical, and useful sense and these happen to be C 
> machines. Why lots of people with ordinary machines can't do something 
> useful, intuitive, and natural because some solder-crazed EE somewhere might,
> just might mind you, someday do something unnatural to his memory system is 
> beyond me.  

Sigh.  Interesting tirade I suppose.  Totally incorrect, of course.  The
problem is not that some hardware or another can or can't do this or
that.  The problem is that, in C, a cast is a unary operator that
produces a new value, and many people are ignorant of this simple fact.
Dragging word-addressed machines into the argument is simply to remind
people of one of the many reasons WHY casts (casts of pointers in
particular) are defined as conversions and not "regard as", and have
nothing whatever to do with the point that they ARE, IN FACT so defined.

> And no noise please about doing something reasonable because 1) we do it 
> all the time with numbers so why not with pointers too,

What, you say things like ((short)i)++ or ((float)i)++ "all the time"?
How... interesting.

>  2) it's probably what you want any way, and

Oh, great.  Just what we need, more constructs that'll "probably" do
what we "want" done.  It's bad enough (in order to allow performance
tradeoffs) that C defines many primitive declarations to be ambiguous,
and I'll even go along with it and proclaim it a Fairly Good Idea.  But
really...  "probably what you want any way" indeed!  Is this any way to
run a language definition?  I doubt it.

> 3) it'll never have to be done on machines that 
> are reasonable to begin with. (By the way there is no reason why ((x+1) = 10)
> shouldn't work too.)

So... 80-mumble-86's are "unreasonable", right?  And PDP-10s, and Crays
(I think), and CDC machines, and many, many more.  "Unreasonable"
computers form a much larger segment of the world than one might think.

And just what will ((x+1) = 10) DO, anyhow?  Oh, I forgot, it'll
"probably do what I want", yeah, that's it.  And (1=2) means to double
all constants in the program at runtime, right?  I mean, it's a
reasonable interpretation, right?  "Probably" what I "wanted" right?
So the compiler should just shut up and do what I said, and not give me
an impertinent error message, right?  Sheesh.

--
The negative judgment is the peak of mentality.
                                --- Alfred North Whitehead
-- 
Wayne Throop      <the-known-world>!mcnc!rti-sel!dg_rtp!throopw