Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!mcsun!ukc!warwick!nott-cs!piaggio!anw From: anw@maths.nott.ac.uk (Dr A. N. Walker) Newsgroups: comp.lang.misc Subject: Re: Relationship between C and C++ Message-ID: <1990Mar22.181947.27026@maths.nott.ac.uk> Date: 22 Mar 90 18:19:47 GMT References: <8432@hubcap.clemson.edu> <5200048@m.cs.uiuc.edu> <4869@vanuata.cs.glasgow.ac.uk> Reply-To: anw@maths.nott.ac.uk (Dr A. N. Walker) Organization: Maths Dept., Nott'm Univ., UK. Lines: 55 In article <4869@vanuata.cs.glasgow.ac.uk> jack@cs.glasgow.ac.uk (Jack Campin) writes: >> Can anyone clue me as to the basis for pointer paranoia? > >Garbage collection, for one. If you try to implement a BCPL-family >language on a machine/OS with garbage-collected object memory [i.e. a >storage model a bit more sophisticated than a Turing machine], you have >real problems identifying what objects are still being referenced when >pointers can be incremented. But pointers can't be incremented off the current object, so the problems are exactly the same for C and Pascal and any other language for which this is a problem at all. Object-bounds checking in C is exactly as hard or easy as array-bounds checking in other languages, so is often "switched off", but that's a different matter. Or are you talking about the inherent insecurities of the "malloc ... free" model of heap storage? If so, this again applies to Pascal, but not to other languages with proper heap mechanisms. In any case, it's a solved problem. >Secondly, real machines are sufficiently different from the Turing tape >that the result of a pointer arithmetic operation is not merely wordsize- >dependent like normal computer "arithmetic", it's OS-dependent. Or do C >fans think it's a good idea to have operator semantics vary with the host >segmentation scheme? I don't understand this either. There is no interesting difference between pa = pa + 5; /* pa points into an array */ and j = j + 5; /* j is being used as an index */ except that if the index or pointer is now illegal, the pointer may be detected instantly whereas the index can't be caught until it is next used. One up to pointers? (If j is a ranged type, the error may then also be caught here, but that's a less flexible solution.) >Thirdly, the aliasing it enables is a semantic mess. If anyone claims >different, let's see your denotational model of ANSI C. Well, I hate denotational semantics, so no offers, but again I don't understand the problem. Yes, aliassing is a problem for optimising compilers, and if used casually is a problem for program-proving; but exactly the same problems arise with arrays, so this isn't a pointer problem, even less a pointer arithmetic problem. Summary: the question was about pointers, but the answers seem to apply to any aliasable or indexable construction, and we're not yet being told that C/Pascal/Fortran/whatever shouldn't have arrays. Or are we? Or am I missing Jack's point? -- Andy Walker, Maths Dept., Nott'm Univ., UK. anw@maths.nott.ac.uk