Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!watmath!clyde!cbosgd!ihnp4!ucbvax!decvax!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.unix-wizards,net.lang.c
Subject: Re: PCC, lint bug
Message-ID: <2774@sun.uucp>
Date: Tue, 10-Sep-85 03:31:51 EDT
Article-I.D.: sun.2774
Posted: Tue Sep 10 03:31:51 1985
Date-Received: Wed, 11-Sep-85 06:29:50 EDT
References: <1024@brl-tgr.ARPA> <1700001@fthood>
Followup-To: net.lang.c
Organization: Sun Microsystems, Inc.
Lines: 34
Xref: watmath net.unix-wizards:14785 net.lang.c:6324

> >Does anybody else think that the array/pointer semi-equivalence is probably
> >one of the major causes of errors in C coding?
> 
> I always thought the array/pointer semi-equivalence was one of the major
> causes of easier to {read,understand} coding.

You missed the point.  The array/pointer semi-equivalence seems to be one of
the major causes of *incorrect* code, as well.  It's not a question of how
readable the code is once it's written, it's a question of whether it'll get
written correctly in the first place.  Every so often, somebody asks why

file1.c:

extern int *foo;

file2.c:

int foo[42];

doesn't work.  The person asking the question obviously doesn't realize that
just because you can say "foo[13]" in either case doesn't mean that the two
declarations mean the same thing.  Another common question is "why doesn't
this work?":

	struct frobozz *foo;

	get_frobozz_value(foo);

which code proceeds to smash some arbitrary location pointed to by the
uninitialized pointer "foo".  I suspect this assumption that a pointer to a
structure, absent a structure for it to point to, is just as good as a
structure is fallout from pointer/array confusion.

	Guy Harris