throopw@dg_rtp.UUCP (Wayne Throop) (06/01/86)
> jsdy@hadron.UUCP (Joseph S. D. Yao) >> sam@delftcc.UUCP (Sam Kendall) >> ... type formal[][]; "is adjusted to read" type (*formal)[]; >>This second type is "pointer to array of unknown length". > > Sam, this is not legal, has never been legal, and (pray God) will > never be legal. Well, sort of. K&R don't mention it. Harbison and Steele *seem* to allow it. And the ANSI draft explicitly disallows it. But, many compilers (and lint) allow it, and it does make the type notation in C more nearly orthogonal and rational. Let's look at what would happen if declarations of the form (*p)[] were unambiguously legal. > tell me: what do arrname[1] or *++ptr reference???? They don't reference anything at all. In particular, the calculation of (p+n), (where p is declared as above, and n is an integer) cannot be done, because the size of *p is unknown. Well, you say. There you are, you say. Can't be did, you say. Not quite, I say. There are two obvious examples of pointers in C which cannot participate in arithmetic operations and the denotation type of which is of unknown size. Pointer-to-function and pointer-to-void. So, a pointer declared with (*p)[] would simply be another case of a pointer type where (sizeof *p) and (p+n) would be illegal. (*p), and (*p)[n], and so on, would still be quite legal. So, while I agree that having arrays of things of unknown size is not very meaningful, I'd say that having pointers to things of unknown size is a venerable tradition in C, with (*p)() being the eldest example. As I say, ANSI currently outlaws (*p)[]. But Harbison and Steele seem to allow for it, lint currently allows it, and most current compilers allow it. I would say that allowing (*p)[] is not much more radical than allowing (*p)(), or (*p)[10]. -- Wayne Throop <the-known-world>!mcnc!rti-sel!dg_rtp!throopw
sam@delftcc.UUCP (Sam Kendall) (06/03/86)
Nice discussion by Wayne Throop. There are a couple of points I'd like
to expand on. First, `T (*)[]' IS unambiguously legal according to K&R.
See section 8.4. Joe, please send me mail if you still disagree.
Second, it's an interesting question as to whether ANSI C should permit
`T (*)[]'. (As Wayne points out, ANSI C prohibits it, in 3.5.3.2.) A
pointer to a dimensionless array is a strange beast, and whether you
allow it or not, some nice property is going to be violated. If you
allow `T (*)[]', you can have a pointer to an object of unknown size.
(Functions have no size, but they are not objects.) The following
property is violated: if `p' is a pointer, then `p' points at either a
function or an object with size. (Bitfields lack size as such, and
you can't point to them.)
But if you disallow `T (*)[]', you do worse, I think. Then there is
only ONE type which cannot have a pointer-to type modifier attached to
it. The following property is violated: if `T' is a type, then `T *' is
also a type.
The real conceptual difficulty, for me, is with the object of unknown
size, not with the pointer to such a thing. If we have to have
objects of unknown size, we might as well permit pointers to such
objects. And do we have to have objects of unknown size? Yes! If
we declare `extern int a[];', then `a' names such an object. Therefore
ANSI C should allow pointers to arrays of unknown size.
One final thought: the burden of proof should be on those who want to
disallow the pointer to dimensionless array. When in doubt, allow it.
And if you don't believe me, you're either more or less confused then I
am. Jeez, this article reads like "C mysticism". No, seriously, it's a
Good Thing to preserve easily-stated properties and orthogonalities and
things like that. Anyone in doubt, read R. D. Tennent's excellent
_Principles of Programming Languages_.
----
Sam Kendall { ihnp4 | seismo!cmcl2 }!delftcc!sam
Delft Consulting Corp. ARPA: delftcc!sam@NYU.ARPA