An occasional essay, meant to inflame interesting discussion. 0-based and 1-based arrays -------------------------- In a typical 0-based array, the allowable index range is from 0 to n - 1. In a typical 1-based array, the allowable index range is from 1 to n. 0-based arrays are compulsory in C, and hence in Mac Toolbox calls. 1-based arrays are compulsory in Fortran and its derivatives such as MatLab, and in some scripting languages. Some languages, such as VisualBasic, allow a choice of 0- or 1-based. Some languages, such as Pascal, allow upper and lower array bounds to be any integer or (almost) any scalar. Arrays in FB and C ------------------ FB's arrays are 0-based, but with an extra element. Storage is reserved for 1 more element than the stated size. The declaration dim as long myArray(10) reserves memory for the 11 elements myArray(0) through myArray(10). The allowable index range is from 0 to n. This unusual definition may have been chosen -- many years ago -- so that simple programs could be written with either 0-based code or 1-based code. Arrays in C are typical 0-based. The declaration int myArray; reserves memory for the 10 elements myArray through myArray. The allowable index range is from 0 to n - 1. Failure to understand this difference between FB and C is responsible for many FB bugs. Commonly they arise in the course of - passing an array to a Toolbox function, or - translating a C struct or Toolbox function declaration into FB. The outcome is often a nasty kind of "off-by-one" error, in this case reading or writing an element that lies just outside the array's declared bounds. The effects of accessing an out-of-bounds array element are undefined. This kind of bug may cause an immediate crash (if you're lucky) or random bad behaviour (if you're not). It can be quite a challenge to debug random crashes of a program that otherwise seems to work properly. 1-based and 0-based code in FB ------------------------------ Some programmers write 1-based code in FB. In so doing they ignore the 0th element and take advantage of FB's "extra" array element. _maxSize = 100 dim as long myArray(_maxSize) dim as long j, n n = something // 0 ≤ something ≤ _maxSize long if ( n != 0 ) for j = 1 to n // do something with myArray(j) next end if Every sensible programmer turns on Array bounds checking (at least during development), because it can catch so many easily-fixed blunders. With the 1-based convention above, it would in general be a bug if the program accessed myArray(0), but the bounds-checker cannot flag that error. I have found that overall I make fewer programming mistakes if I consistently treat FB's arrays as 0-based. _maxSize = 100 dim as long myArray(_maxSize) dim as long j, n n = something // 0 ≤ something ≤ _maxSize j = 0 while ( j < n ) // do something with myArray(j) j++ wend The code can access myArray(0) through myArray(99), but not the "extra" hundred-and-first element myArray(100). Although the presence of the extra element is often harmless, I prefer (when I remember) to eliminate it by declaring: dim as long myArray(_maxSize - 1) With that declaration, the compiler-inserted array bounds-checking code is reliable. Both the compiler and I agree that the array contains exactly 100 accessible elements, and any transgression beyond the bounds will be flagged at runtime. For an entertaining discussion of the 0-based 1-based issue, see <http://c2.com/cgi/wiki?ZeroAndOneBasedIndexes> Robert P.