Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!rpi!uupsi!rodan.acs.syr.edu!isr
From: isr@rodan.acs.syr.edu (Michael S. Schechter - ISR group account)
Newsgroups: comp.society.futures
Subject: Re: C's sins of commission (was: (pssst...fortran?))
Message-ID: <1990Sep21.181433.16283@rodan.acs.syr.edu>
Date: 21 Sep 90 18:14:33 GMT
References: <1990Sep20.161852.22977@rodan.acs.syr.edu> <63613@lanl.gov>
Organization: Institute for Sensory Research
Lines: 31

In article <63613@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>From article <1990Sep20.161852.22977@rodan.acs.syr.edu>, by isr@rodan.acs.syr.edu (Michael S. Schechter - ISR group account):
>> Now in C it's easy to go MyPtr=(Pointer)0x100  [...]
>Well, yes, you can do that in some extended versions of C no doubt.
>You could extend Fortran to do such things too.  But, _standard_
I'm sorry, ANSI can dream all they want, 
I think you'll find that most people will
agree that K&H is 'standard' C, NOT ANSI.
That's why the compiler mfr's advertise that
they support ANSI, because it's NOT standard enough
to be assumed.
AND AS YOU SAY:  "You ****could**** extend Fortran"
Yeah, but i do real work, not write preproccessors, that's better
left as exercises for students. And since virtually every
****EXISTING**** C will allow it in some way, why bother doing
Satan's work and extending Fortran?

>C leaves the result of that cast undefined.  For example, on a
>segmented machine, the above statement _may_ put the number 0x100
Out of context, your point is valid,  however I was talking about hardware
addresses, presumably, the system programmer or real-time programmer
(ones who _must_ access hardware, not just use system calls)
knows what must be done to get valid pointers.

Enough.
I quit.


--
Mike Schechter, Computer Engineer,Institute Sensory Research, Syracuse Univ.
InterNet: Mike_Schechter@isr.syr.edu isr@rodan.syr.edu Bitnet: SENSORY@SUNRISE