On 8/15/2010 4:00 AM, Lawrence D'Oliveiro wrote:
In message<mailman.2071.1281719688.1673.python-l...@python.org>, Thomas
Jollans wrote:
"Where it all started" is that 0-based indexing gives languages like C a
very nice property: a[i] and *(a+i) are equivalent in C. From a language
design viewpoint, I think that's quite a strong argument.
It would be if pointers and arrays were the same thing in C. Only they’re
not, quite. Which somewhat defeats the point of trying to make them look the
same, don’t you think?
In retrospect, C's "pointer=array" concept was a terrible mistake.
It's a historical artifact; early C (pre K&R, as shipped with
"research UNIX" V6 and PWB) had no notion of typing; all "struct"
pointers were interchangeable and elements of a "struct" were just
offsets of a pointer. That was fixed, but arrays weren't.
The fundamental problem with "array=pointer" is that it results
in lying to the language. Consider the declaration of "read":
int read(int fd, char* buf, size_t n);
This is a a lie. "buf" is not a pointer to a character. It's an
array. And, the bad part, the compiler doesn't know how big it is.
The syntax should have been something like
int read(int fd, &char[n] buf, size_t n);
This says the type of the argument is an array of char of
length n, and it's being passed by reference. "read"
then knows how big "buf" is.
This design error in C is the cause of most buffer overflow
crashes and security holes.
John Nagle
--
http://mail.python.org/mailman/listinfo/python-list
