🚀 go-pugleaf

In article <14312@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
> Non-segmented byte-addressible machine don't exhibit the failing that you
> give as the reason for limiting pointer values to only lie within the
> allocated object!  Apparently, you are willing to reinterpret the context
> of this discussion to fit your preconceptions any time you feel like it.

Nah, I'm not *in* this discussion. I'm just sitting on the side pointing out
things you guys miss. Like, the fact that C can run at all in such a minimal
implementation has proven to be one of it's strengths. How many PD Fortran
compilers are there?

> You imply that many implementations actually
> allocate an extra element at the end for the 'dispensation' on pointer
> values at one past the end.

No, that was someone else. But, yes, many low-end implementations on machines
like the IBM-PC have done so. And the IBM-PC is probably the major C user base
right now... and it's a segmented byte-addressible machine. C doesn't fit so
well into it, but it's easy enough to make it look like a flat address space,
subject to some limitations, so long as you allocate those extra bytes for
breathing room.

> Are you saying that this implementation should be regarded as anything but
> poor?

No. But it's also cheap. And look at what it's got to work with.

> By the way, pascal doesn't _have_ pointer arithmetic.  So this whole issue
> doesn't arise there.

Pascal is also such a limited language that it's heavily fragmanted.
Portability between compilers... let along machines... is practically non-
existent. Because to do much of anything interesting in it you need to
use extensions. You don't write in "Pascal". You write in Turbo-pascal, or
Oregon pascal/2, or UCSD Pascal, or JRT Pascal, or Alice, or whatever...
-- 
 _--_|\  `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
/      \  'U`
\_.--._/
      v