Path: utzoo!attcan!uunet!bu.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!yale!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.society.futures
Subject: Re: C's sins of commission (was: (pssst...fortran?))
Message-ID: <63613@lanl.gov>
Date: 20 Sep 90 19:49:40 GMT
References: <1990Sep20.161852.22977@rodan.acs.syr.edu>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 32

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_
C leaves the result of that cast undefined.  For example, on a
segmented machine, the above statement _may_ put the number 0x100
into the offset part of MyPtr - leaving the segment part of the
pointer unchanged - and _still_ be standard conforming C.  This is
fine if it is what you want, but you may have intended that the
statement set the segment address as well as the offset.

> [...]                                            In fortran, it's a
> pain.  [...]

In _standard_ C it's a pain.  Some extended Fortran's I've seen will
let me declare an array and base it at any hardware address I want.
Some PC users do this to allow them to address display memory as a
simple 2-d array.  Presumably, _extended_ versions of C can do the same.
But, we were talking about _legal_ uses of the language as defined
by the appropriate language definition.

> [...]
> This further illustrates what started the entire thread-
> FORTRAN is UGLY and a PAIN for things that use a lot of pointers.

Perhaps it's the use of pointers that's "UGLY and a PAIN".  It's maybe
less ugly in C, but it's usually not necessary elsewhere.  In fact,
it's usually better not to use pointers at all if they can be avoided.

J. Giles