Why index starts in C from 0 and not 1

[kal]

To someone with a solid assembly background, 0-based indexing appears as
the most natural option, because this is how indexed addressing modes
work on most processors supporting them. And the processor for which
C was originally designed was no exception.

I don't have a solid background in assembly, or in anything
else for that matter; still, I find zero based counting
(not to mention indexing) convenient.

For instance, if the years had started at 0 we wouldn't have
had all the argument about if 2000 or 2001 is the start of the
new millennium.

Zero based counting also uses the full value set of any given
number of bits.

Then there are conveniences such as:

string[length] = 0;

for(i = 0; i < size; i++) a += b[i%8];

IMHO the list is quite long. So, the question should not be
why the indexing starts at zero in C but rather why it doesn't
start at zero in some languages.

Dan

Hope you had a great vacation.
</OT>

 

[Dan Pop]

In <[email protected]> "Allan Bruce"


The most popular languages at the time C was designed used 1-based
indexing: FORTRAN, BASIC, Pascal.

Quibble: Pascal allows arrays to be based however the user specifies.
For example (if I remember the syntax correctly):

type
My_Array = array[37 .. 42] of Integer;

So does F77, IIRC, but the default is 1-based indexing.

Dan

 

[Richard Tobin]

Not a satisfactory explanation.

Not a satisfactory exlpanation of what?

-- Richard

 

[Does It Matter]

That's incorrect (the PDP-11 has 8 addressing modes - including offsets
from a register value).

Obviously, from the number of people who corrected me, you are correct. It
has been a long time since I used PDP-11 assembly and my memory has
obviously failed me.

Thank you for correcting me.

 

[James Dow Allen]

I know that the array index starts in C from 0 and not 1 can any
body pls. tell me the reason.

I've appended an excerpt from
http://tinyurl.com/2452h/lesson5.htm

James

* * *& * * * * * * * * *

Realizing that *ptr and ptr[0] are synonyms
[when evaluated as expressions],
and that & is just the inverse of *,
we know immediately that all of the following
(or rather that subset of them
legal in a given context) must be equivalent:

* ptr
* * & ptr
* & * ptr
& * * ptr /* legal if (*ptr) is a pointer */
& & * * * ptr /* legal if (**ptr) is a pointer */
* (ptr + 0)
ptr [0]

Appreciate the sheer simplicity and elegance !
Note that C's choice of 0 for the first index of
an array follows as the night the day as long
as we insist that

ptr == ptr + 0

......

 

[Chris Torek]

I've appended an excerpt from
http://tinyurl.com/2452h/lesson5.htm
& & * * * ptr /* legal if (**ptr) is a pointer */

This one is wrong. The rest appear to be correct, at least in
C99.

C89 and C99 are rather different here -- in C89, "&" and "*" do
not "automatically cancel", as it were, so if p == NULL, then the
expression:

p == NULL

is always OK (and produces the "int" value 1), but:

&(*p) == NULL

is an error in C89, but valid in C99. (The C99 way is "better",
in my opinion. The C89 restriction allows a really stupid compiler
to generate code to follow the pointer, even though the result of
that indirection is never used. I find it hard to imagine that a
compiler could do this and yet still get the right answer -- the
"int" value 0 -- when p is both valid and non-NULL.)

The problem with "& & * * ptr" is that the operand of the first
"&" is another "&", which produces a value ("rvalue") rather than
an object ("lvalue", more or less, except for the bizarre redefinition
in C99). The "&" operator can only be applied to objects.

Clearly, if we were to have the inner "&*" pair cancel out first,
then (not legal C syntax):

(&(&*)*) *ptr

would have the inner parenthesized sequence drop out, leaving:

(&*) *ptr

which would then have the parenthesized pair drop out, leaving just
"*ptr". Unfortunately, nothing says the cancelling is done inside-out
like this; and in fact, gcc -- assuming gcc is correct here! --
says:

foo.c:2: invalid lvalue in unary `&'

(under both -std=c89 and -std=c99).