dick@cs.vu.nl (Dick Grune) (06/02/88)
Two weeks ago I posted an enquiry on the name of the first non-entry in an array, to use as a limit in testing. I received 7 answers, from which no clear consensus emerged. Two people argue convincingly that using the number of elements and using the address of the last+1 item is actually the same thing. They advocate tests like: if (p >= &array[N]) error(...); and loops like: for (p = &array[0]; p < &array[N]; p++) process(*p); both of which look sane and understandable. I seriously thought about adopting these "templates" systematically in my coding, when I realized that for it to work, you would have to declare N as a long. Otherwise you lose on machines with 2-byte ints and 4-byte pointers. (I know, I know, the Kernighan & Ritchie book does not allow these, but they do exist.) Now this is something somebody will go and make mistakes with, me first of all, and the point of the exercise was to avoid errors. Back to names for the elusive element after all elements. Suggestions were: array_Nth, array_last1, array_guard, array_meta, array_end (vs. array_last for &array[N-1]), array_limit; all suggested once. Going through my programs I see that I have used array_limit, array_FF, array_first_not_in (vs. array_first_in, I must have been doing this by gross editing!) and array_end. I like the _meta; it means "past", "after"; but it needs an explanation to be understood (but perhaps every word for this notion will). Array_end and array_limit sound more normal but do not convey the notion. Perhaps a new notion needs a new word. In that case _meta is a good candidate. Dick Grune Vrije Universiteit de Boelelaan 1081 1081 HV Amsterdam the Netherlands dick@cs.vu.nl ...!mcvax!vu44!dick
karl@haddock.ISC.COM (Karl Heuer) (06/06/88)
In article <778@dick.cs.vu.nl> dick@cs.vu.nl (Dick Grune) writes: > if (p >= &array[N]) ... > for (p = &array[0]; p < &array[N]; p++) ... >both of which look sane and understandable. I seriously thought about >adopting these "templates" systematically in my coding, when I realized that >for it to work, you would have to declare N as a long. Otherwise you lose on >machines with 2-byte ints and 4-byte pointers. It's not the size of a pointer that matters; it's just a question of what is the maximum size of an array. (I.e., if you have 4-byte pointers but no array can ever have more than 65535 elements, then a 2-byte int will suffice.) This has nothing to do with "&array[N]" vs. "array+N"; either both will work, or neither. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint Followups to comp.lang.c.
bill@proxftl.UUCP (T. William Wells) (06/19/88)
In article <778@dick.cs.vu.nl>, dick@cs.vu.nl (Dick Grune) writes:
) Two people argue convincingly that using the number of elements and
) using the address of the last+1 item is actually the same thing. They advocate
) tests like:
)
) if (p >= &array[N])
) error(...);
)
) and loops like:
)
) for (p = &array[0]; p < &array[N]; p++)
) process(*p);
)
) both of which look sane and understandable. I seriously thought about adopting
) these "templates" systematically in my coding, when I realized that for it to
) work, you would have to declare N as a long. Otherwise you lose on machines
) with 2-byte ints and 4-byte pointers.
The new C standard has a fix for this. One can even use this
with current code. Declare any variable which contains the size
of an object as of type size_t. If you are using Standard C,
include <stddef.h>; if not, add to your program an appropriate
typedef for it. K&R compatible compilers would use typedef
unsigned size_t; compilers with longer addresses would use
typedef unsigned long size_t. (There is an equivalent type for
the difference between two pointers, ptrdiff_t; I suggest using
this as well.