Xref: utzoo comp.databases:1738 comp.lang.c:14922 comp.unix.xenix:4222
Checksum: 60284
Lines: 32
Path: utzoo!sq!msb
From: msb@sq.uucp (Mark Brader)
Date: Tue, 20-Dec-88 00:03:09 EST
Message-ID: <1988Dec20.000309.17955@sq.uucp>
Newsgroups: comp.databases,comp.lang.c,comp.unix.xenix
Subject: Re: Style (was: C-DATABASE B-PLUS a quick look)
References: <179@lakesys.UUCP> <2404@xyzzy.UUCP>
Reply-To: msb@sq.com (Mark Brader)
Organization: SoftQuad Inc., Toronto

Wayne A. Throop (throopw@xyzzy.UUCP) made, in <2404@xyzzy.UUCP>, some
criticisms of a certain piece of code including these lines:

> >           int p = 0;
> >           while ( s[p] != NULL ) {

The last of these was:

> Fifth, the object of this exercise is somewhat more naturally cast in
> terms of pointers rather than subscripting in C.

Wayne went on to cite two admittedly minor justifications for this.
And I'd like to add another: avoiding the use of "int" for the subscript!

Remember that "int" is allowed to be as small as 16 bits.  It is quite
conceivable that s[] has more than 32767 elements in it, so p can
overflow, followed by God-knows-what (or as the X3J11 people say, by
"undefined behavior").  A similar problem can exist if we make p "unsigned";
in this case it would be an infinite loop.

On the other hand, some compilers wouldn't allow the object's dimension
to exceed an int's range, so declaring p as "long" could be wasteful.

If we use pointers instead of subscripts to step through the array,
no such problem can exist.  A pointer that points to the beginning of
an array is guaranteed to be incrementable to the end of the array
(plus one more time, in Draft ANSI C); and there is only one size of
pointer variable (in true C, anyway): the right size.

Mark Brader				"Those who do not understand UNIX
SoftQuad Inc., Toronto			 are condemned to repeat it."
utzoo!sq!msb, msb@sq.com				-- Henry Spencer