Why are the following declarations invalid in C?

int f()[];
int f()[10];

It would be great if anyone could also explain the design decision
for such a language restricton.

Regards,
Sanjay

In article <fd8bc102-b012-4cd2-81ed-da90cde5adfa@1g2000prg.googlegroups.com>,
sanjay.vasudevan@gmail.com <sanjay.vasudevan@gmail.com> wrote:

>Why are the following declarations invalid in C?

>int f()[];
>int f()[10];

>It would be great if anyone could also explain the design decision
>for such a language restricton.

Where would the array get temporarily stored? Who would be responsible
for freeing it?

In a stack-based machine that mixes parameters and control, the
information for the called routine is already on the stack by the time
the hypothethical return array is created. As the return array could
be of any size, the caller cannot know how much space to reserve
"under" the stack frame for the called routine. Therefor the called
routine would either have to somehow insert the space for the array
"above" the stack frame for the routine itself (so that it still
exists when the routine returns), or else the called routine would
have to return an address of the array. If it returns an address of
the array, the address cannot be that of an automatic variable in
the called routine, as after the call those automatic variables
become inaccessible. It can't use a static variable because it doesn't
know the maximum size. So the only way to make that work would be
to malloc() an array to store the data into, store the data, and
return the pointer to the malloc'd area. But then what's the contract
about who frees the array? If you require that the calling routine
-automatically- frees the array, then you add noticable complexity
to the language. If you require that the calling routine -explicitly-
free the array, then you have no more expressive power than you
already have available by making the return type a pointer and returning
the pointer to a malloc'd area.
--
"History is a pile of debris" -- Laurie Anderson

Walter Roberson wrote:
> In article <fd8bc102-b012-4cd2-81ed-da90cde5adfa@1g2000prg.googlegroups.com>,
> sanjay.vasudevan@gmail.com <sanjay.vasudevan@gmail.com> wrote:
>
>> Why are the following declarations invalid in C?
>
>> int f()[];
>> int f()[10];
>
>> It would be great if anyone could also explain the design decision
>> for such a language restricton.
>
> Where would the array get temporarily stored?

Either in its final destination or in a temporary variable, as
all results from functions.

> Who would be responsible
> for freeing it?
>

Nobody, it would be either in a result variable or in a
temporary with automatic storage type.

> In a stack-based machine that mixes parameters and control, the
> information for the called routine is already on the stack by the time
> the hypothethical return array is created. As the return array could
> be of any size, the caller cannot know how much space to reserve
> "under" the stack frame for the called routine. Therefor the called
> routine would either have to somehow insert the space for the array
> "above" the stack frame for the routine itself (so that it still
> exists when the routine returns), or else the called routine would
> have to return an address of the array. If it returns an address of
> the array, the address cannot be that of an automatic variable in
> the called routine, as after the call those automatic variables
> become inaccessible. It can't use a static variable because it doesn't
> know the maximum size. So the only way to make that work would be
> to malloc() an array to store the data into, store the data, and
> return the pointer to the malloc'd area. But then what's the contract
> about who frees the array? If you require that the calling routine
> -automatically- frees the array, then you add noticable complexity
> to the language. If you require that the calling routine -explicitly-
> free the array, then you have no more expressive power than you
> already have available by making the return type a pointer and returning
> the pointer to a malloc'd area.


Then, please tell me why this works?

struct f { int array[80];};

struct f function(void)
{
struct f result;
return result;
}

This is the same.

Functions can't return arrays because... an arbitrary
decision was done ages ago that must be preserved so that
new software remains compatible with the errors of
the past.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

sanjay.vasudevan@gmail.com wrote:
> Why are the following declarations invalid in C?
>
> int f()[];
> int f()[10];
>
> It would be great if anyone could also explain the design decision
> for such a language restricton.
>
> Regards,
> Sanjay

There is no reason. It is just a design mistake of the language.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

"Walter Roberson" <roberson@ibd.nrc-cnrc.gc.ca> wrote in message
news:fu0j1h$62s$1@canopus.cc.umanitoba.ca...
> In article
> <fd8bc102-b012-4cd2-81ed-da90cde5adfa@1g2000prg.googlegroups.com>,
> sanjay.vasudevan@gmail.com <sanjay.vasudevan@gmail.com> wrote:
>
>>Why are the following declarations invalid in C?
>
>>int f()[];

>>int f()[10];
>
>>It would be great if anyone could also explain the design decision
>>for such a language restricton.
>
> Where would the array get temporarily stored? Who would be responsible
> for freeing it?
>

This is no different to the problem of returning a struct of arbitrary (but
known) size.

> As the return array could be of any size

I thought C arrays were always a known fixed size, apart from VLAs.

I think it was just decided that arrays and structs should behave
differently (because arrays are a little special), and there is no technical
reason why arrays cannot be passed to and returned from functions.

--
Bart

Bartc wrote:
>
> I think it was just decided that arrays and structs should behave
> differently (because arrays are a little special), and there is no technical
> reason why arrays cannot be passed to and returned from functions.
>

Exactly. I am of the same opinion.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

On Apr 14, 2:25pm, "sanjay.vasude...@gmail.com"
<sanjay.vasude...@gmail.com> wrote:
> Why are the following declarations invalid in C?
>
> int f()[];
> int f()[10];
>
> It would be great if anyone could also explain the design decision
> for such a language restricton.

I think it is basically the same idea as the electoral college:
"Let's protect them from their own stupidity."

Of course, you can do this:
struct array_wrapper {
int foo[100];
};
and return one of those.

"Bartc" <bc@freeuk.com> writes:

> I think it was just decided that arrays and structs should behave
> differently (because arrays are a little special), and there is no technical
> reason why arrays cannot be passed to and returned from functions.

A little history... The situation was not so odd at first. For some
time C restricted parameters and returned results to the basic types.
By the time that struct passing and returning was added, it was too
late to re-visit the secondary position held by arrays.

--
Ben.

In article <fu0k3u$kvl$3@aioe.org>, jacob navia <jacob@nospam.org> wrote:

>> I think it was just decided that arrays and structs should behave
>> differently (because arrays are a little special), and there is no
>> technical reason why arrays cannot be passed to and returned from
>> functions.

>Exactly. I am of the same opinion.

If you were designing the language from scratch, it would be no
problem. But you'll have trouble fitting it in now. The natural
syntax is already taken. How would you pass or return an array? You
can't just use its name, because that syntax is already used for
passing or returning the address of the first element. How can you
declare the formal argument? Same problem.

-- Richard
--
:wq

sanjay.vasudevan@gmail.com writes:
> Why are the following declarations invalid in C?
> int f()[];
> int f()[10];

Probably because of the language (mis)feature that array expressions
often decay to pointers to the first element of the array.

What would you do with that function? The 2nd variant:
int a[10] = f();
would presumably be a case of assigning the contents of an array to
another array, which C does not support. This won't compile either:
int a[10], b[10];
void foo() { a = b; }

Or if you would do this:
foo() { int *a; ... { ... a = f(); ... } }
then there is still an array-to-array assignment going on, only this
time to a temporary variable on the stack. However in this case it's
worse: The compiler may not be able to tell when the temporary becomes
"dead" so the space can be reused. It'd have to keep it around until
the function returns. This is because it created a pointer to the
temporary, which it won't do with other kinds of temporaries.


Your first version is worse still, int *a = f() would need to return
data of unknown size and put it on the stack.

--
Hallvard

Richard Tobin wrote:

> If you were designing the language from scratch, it would be no
> problem. But you'll have trouble fitting it in now. The natural
> syntax is already taken. How would you pass or return an array? You
> can't just use its name, because that syntax is already used for
> passing or returning the address of the first element. How can you
> declare the formal argument? Same problem.

Further, arrays aren't modifiable lvalues. You can't assign the results
of the function to an array, which limits the usefulness to a degree.
You would really have start over and make arrays a first-class type.




Brian

"Hallvard B Furuseth" <h.b.furuseth@usit.uio.no> wrote in message
news:hbf.20080415l0zd@bombur.uio.no...
> sanjay.vasudevan@gmail.com writes:
>> Why are the following declarations invalid in C?
>> int f()[];
>> int f()[10];
>
> Probably because of the language (mis)feature that array expressions
> often decay to pointers to the first element of the array.
>
> What would you do with that function? The 2nd variant:
> int a[10] = f();
> would presumably be a case of assigning the contents of an array to
> another array, which C does not support. This won't compile either:
> int a[10], b[10];
> void foo() { a = b; }
>
> Or if you would do this:
> foo() { int *a; ... { ... a = f(); ... } }
> then there is still an array-to-array assignment going on, only this
> time to a temporary variable on the stack. However in this case it's
> worse: The compiler may not be able to tell when the temporary becomes
> "dead" so the space can be reused. It'd have to keep it around until
> the function returns. This is because it created a pointer to the
> temporary, which it won't do with other kinds of temporaries.

*a is a pointer to int. f() returns an array of int. So there is a type
mismatch and this should not compile, and the problem would not arise. I
don't think you can reasonably expect an array returned by a function to
'decay' to a pointer in the same way as a normal array.

(Creating a pointer to a value returned by a function is not a good idea
anyway, array or not)

--
Bart

In article <4rQMj.8286$yD2.4203@text.news.virginmedia.com> "Bartc" <bc@freeuk.com> writes:
....
> I think it was just decided that arrays and structs should behave
> differently (because arrays are a little special), and there is no technical
> reason why arrays cannot be passed to and returned from functions.

Originally functions could also not return structs (and they could not
be passed as parameters). Currently both are allowed for structs, but
none is allowed for arrayes. I think the reason is that passing an
array as a parameter had already an established meaning (pass the address
for the first element).
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

In article <fu0k3u$kvl$3@aioe.org> jacob@nospam.org writes:
> Bartc wrote:
> >
> > I think it was just decided that arrays and structs should behave
> > differently (because arrays are a little special), and there is no technical
> > reason why arrays cannot be passed to and returned from functions.
>
> Exactly. I am of the same opinion.

There is no technical reason. But it was already established long ago that
when an actual parameter was an array that what would be passed was not the
array but the address of the first element. Changing that to actually
passing the array would break a lot of code.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

On Mon, 14 Apr 2008 21:57:20 GMT, "Bartc" <bc@freeuk.com> wrote in
comp.lang.c:

>
> "Walter Roberson" <roberson@ibd.nrc-cnrc.gc.ca> wrote in message
> news:fu0j1h$62s$1@canopus.cc.umanitoba.ca...
> > In article
> > <fd8bc102-b012-4cd2-81ed-da90cde5adfa@1g2000prg.googlegroups.com>,
> > sanjay.vasudevan@gmail.com <sanjay.vasudevan@gmail.com> wrote:
> >
> >>Why are the following declarations invalid in C?
> >
> >>int f()[];
>
> >>int f()[10];
> >
> >>It would be great if anyone could also explain the design decision
> >>for such a language restricton.
> >
> > Where would the array get temporarily stored? Who would be responsible
> > for freeing it?
> >
>
> This is no different to the problem of returning a struct of arbitrary (but
> known) size.

This is true, but the in the early days of C one could not pass or
return structures by value, either. They were mentioned as a feature
that was coming, but not yet available on all implementations, in the
original K&R.

C was originally developed to create executables for extremely memory
constrained platforms. It is still widely used for that purpose in
embedded systems, the major use of C today.

Once you added the ability to pass and return structures by value, you
have the ability to define your arrays inside of structures and do
this when you want.

Since you have the ability to do it with structs, you do not risk
serious code breakage that could have occurred due to the (IMO
unfortunate) conversion of array arguments to pointer arguments in
function definitions (also declarations and, much later, prototypes).

Code like this:

int func1(ap)
int *ap;

....would continue to work as before, and:

int func1(ap)
int ap[];

....would continue to work as before, but:

int func1(ap)
int ap[10];

....might suddenly work very differently. Especially in the absence of
prototypes.

Adding pass and return of structs by value did not break existing
code. Passing arrays by value most certainly would have.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

On Mon, 14 Apr 2008 23:55:21 +0200, jacob navia <jacob@nospam.com>
wrote in comp.lang.c:

> sanjay.vasudevan@gmail.com wrote:
> > Why are the following declarations invalid in C?
> >
> > int f()[];
> > int f()[10];
> >
> > It would be great if anyone could also explain the design decision
> > for such a language restricton.
> >
> > Regards,
> > Sanjay
>
> There is no reason. It is just a design mistake of the language.

That is, in the opinion of the very opinionated Jacob Navia.

I happen to think it was a good choice. For about 30 years now you
have been able to pass and return fixed-size arrays by value by
wrapping them in a structure.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

On Apr 15, 2:41 am, rober...@ibd.nrc-cnrc.gc.ca (Walter Roberson)
wrote:
> In article <fd8bc102-b012-4cd2-81ed-da90cde5a...@1g2000prg.googlegroups.com>,
>
> sanjay.vasude...@gmail.com <sanjay.vasude...@gmail.com> wrote:
> >Why are the following declarations invalid in C?
> >int f()[];
> >int f()[10];
> >It would be great if anyone could also explain the design decision
> >for such a language restricton.
>
> Where would the array get temporarily stored? Who would be responsible
> for freeing it?
>
> In a stack-based machine that mixes parameters and control, the
> information for the called routine is already on the stack by the time
> the hypothethical return array is created. As the return array could
> be of any size, the caller cannot know how much space to reserve
> "under" the stack frame for the called routine. Therefor the called
> routine would either have to somehow insert the space for the array
> "above" the stack frame for the routine itself (so that it still
> exists when the routine returns), or else the called routine would
> have to return an address of the array. If it returns an address of
> the array, the address cannot be that of an automatic variable in
> the called routine, as after the call those automatic variables
> become inaccessible. It can't use a static variable because it doesn't
> know the maximum size. So the only way to make that work would be
> to malloc() an array to store the data into, store the data, and
> return the pointer to the malloc'd area. But then what's the contract
> about who frees the array? If you require that the calling routine
> -automatically- frees the array, then you add noticable complexity
> to the language. If you require that the calling routine -explicitly-
> free the array, then you have no more expressive power than you
> already have available by making the return type a pointer and returning
> the pointer to a malloc'd area.
> --
> "History is a pile of debris" -- Laurie Anderson

I & Sanjay had this discussion on the returning array by functions.
Lets say that the language allowed 2 things.
1. Return array from a function by just copying the address of the
first element.
2. Creating array aliases like regular variables.

What would be wrong with the following code then:

int[] func2(int a[]);
void func1()
{
int a[5];
int &b[]=func2(a);//b is some sort of an alias to the returned type
}
int[] func2(int a[])
{
//do something
return a;
}

Default User wrote:
> Richard Tobin wrote:
>
>> If you were designing the language from scratch, it would be no
>> problem. But you'll have trouble fitting it in now. The natural
>> syntax is already taken. How would you pass or return an array? You
>> can't just use its name, because that syntax is already used for
>> passing or returning the address of the first element. How can you
>> declare the formal argument? Same problem.
>
> Further, arrays aren't modifiable lvalues. You can't assign the results
> of the function to an array, which limits the usefulness to a degree.
> You would really have start over and make arrays a first-class type.

And you'd need to re-think the entire topic of pointers.
And you'd need to invent a new way of dealing with strings
(e.g., if a string is a specially-formatted array of char, as
now, then what would strtok() or strstr() return?).

--
Eric Sosman
esosman@ieee-dot-org.invalid

Bartc writes:
Hallvard B Furuseth" <h.b.furuseth@usit.uio.no> wrote in message
>news:hbf.20080415l0zd@bombur.uio.no...
>> sanjay.vasudevan@gmail.com writes:
>>> Why are the following declarations invalid in C?
>>> int f()[];
>>> int f()[10];
>>(...)
>> Or if you would do this:
>> foo() { int *a; ... { ... a = f(); ... } }
>> then there is still an array-to-array assignment going on, only this
>> time to a temporary variable on the stack. However in this case it's
>> worse: The compiler may not be able to tell when the temporary becomes
>> "dead" so the space can be reused. It'd have to keep it around until
>> the function returns. This is because it created a pointer to the
>> temporary, which it won't do with other kinds of temporaries.
>
> *a is a pointer to int. f() returns an array of int. So there is a type
> mismatch and this should not compile, and the problem would not arise. I
> don't think you can reasonably expect an array returned by a function to
> 'decay' to a pointer in the same way as a normal array.

No, I don't expect that - because the language forbinds "int f()[10]".
However, yes I do expect "a = <expression of type array of int>" to be
treated the same way regardless of where that expression comes from.
If it did not, just what should the program be allowed to do with it?
Would &f() be OK? *&f()? f()[0]? &f()[0]?

To get this to work cleanly, the language basically needs a new class of
types: "array which does not decay to a pointer". Given that, one can
decide just how such a type can be used, and you'll also have the
answer to all of the above.

--
Hallvard

Hallvard B Furuseth wrote:
[snip]
> To get this to work cleanly, the language basically needs a new class of
> types: "array which does not decay to a pointer". Given that, one can
> decide just how such a type can be used, and you'll also have the
> answer to all of the above.
>

lcc-win features this kind of array using operator overloading.

Arrays that do not decay into pointers are very useful for making
o bound checked arrays easily
o Counted strings
and many other applications




--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

"Hallvard B Furuseth" <h.b.furuseth@usit.uio.no> wrote in message
news:hbf.20080415ngx4@bombur.uio.no...
> Bartc writes:
> Hallvard B Furuseth" <h.b.furuseth@usit.uio.no> wrote in message
>>news:hbf.20080415l0zd@bombur.uio.no...
>>> sanjay.vasudevan@gmail.com writes:
>>>> Why are the following declarations invalid in C?
>>>> int f()[];
>>>> int f()[10];
>>>(...)
>>> Or if you would do this:
>>> foo() { int *a; ... { ... a = f(); ... } }

>> *a is a pointer to int. f() returns an array of int. So there is a type
>> mismatch and this should not compile, and the problem would not arise. I
>> don't think you can reasonably expect an array returned by a function to
>> 'decay' to a pointer in the same way as a normal array.
>
> No, I don't expect that - because the language forbinds "int f()[10]".
> However, yes I do expect "a = <expression of type array of int>" to be
> treated the same way regardless of where that expression comes from.
> If it did not, just what should the program be allowed to do with it?

Well, it could be assigned to an array:

*a=f(); where a already points to a suitable space. Or possibly:

int b[10];
b=f();

Or it could be passed directly to another function that takes arrays of the
same size:

g(f());

> Would &f() be OK? *&f()? f()[0]? &f()[0]?
>
> To get this to work cleanly, the language basically needs a new class of
> types: "array which does not decay to a pointer". Given that, one can
> decide just how such a type can be used, and you'll also have the
> answer to all of the above.

Actually, adding such a new type of array wouldn't be that much of a
problem. But the special interaction between newarrays and pointers wouldn't
exist in the same way as for ordinary arrays.

So setting up dynamic arrays and indexing them as though they were fixed
arrays would not be possible.

So I don't see such newarrays being popular with C aficionados. Especially
as these arrays would have to be a fixed size so would have the same
limitations as early Pascal.

A new array type needs something extra, and that would need to be flexible
bounds, or bounds that are passed around with the array. But then, this
would be taking C to a slightly different level.

--
Bart

On Apr 14, 10:01 pm, Jack Klein <jackkl...@spamcop.net> wrote:
> On Mon, 14 Apr 2008 23:55:21 +0200, jacob navia <ja...@nospam.com>
> wrote in comp.lang.c:
>
> > sanjay.vasude...@gmail.com wrote:
> > > Why are the following declarations invalid in C?
>
> > > int f()[];
> > > int f()[10];
>
> > > It would be great if anyone could also explain the design decision
> > > for such a language restricton.
>
> > > Regards,
> > > Sanjay
>
> > There is no reason. It is just a design mistake of the language.
>
> That is, in the opinion of the very opinionated Jacob Navia.
>
> I happen to think it was a good choice. For about 30 years now you
> have been able to pass and return fixed-size arrays by value by
> wrapping them in a structure.
>

But that just brings up the question, why can you return structs
containing arrays by value, but not arrays themselves? Surely any
*technical* issue for one is just as valid for the other; so why the
difference?

I *suspect* the reason behind the OP's query is that array objects are
non-modifiable lvalues:

int a[10], b[10];
b = a; /* illegal! */

Since you can't assign a new array value to an array type object, it
doesn't make sense to allow functions to return array types. That
would make it not a mistake in design for no good reason (per Jacob),
but a consequence of how arrays are handled by the rest of the
language. Whether "how arrays are handled by the rest of the
language" is a mistake in design or not is an open issue.

"sanjay.vasudevan@gmail.com" <sanjay.vasudevan@gmail.com> writes:
> Why are the following declarations invalid in C?
>
> int f()[];
> int f()[10];
>
> It would be great if anyone could also explain the design decision
> for such a language restricton.

Handling arrays as first-class types and objects turns out to be a
non-trivial language design problem.

As others have mentioned, C didn't originally allow structures to be
assigned, passed as arguments, or returned as function results.
Adding this functionality wasn't much of a problem, partly because all
structures of a given type are the same size. The only really new
thing was that some operations required copying arbitrarily large (but
fixed) amounts of data, possibly by implicitly invoking memcpy() or
something like it.

A major for arrays is that array names are usually converted to
pointers; defining the syntax for first-class array objects and values
without breaking existing code would be difficult.

Also, arrays of a given type can usefully have different sizes.

Let's assume that we can work around the existing code problem by
defining a new kind of array, one that doesn't decay to a pointer.

Assume that f is a function that returns an array of int. Presumably
you'd want to be able to do something like this:

int arr[100];
arr = f();

What if f returns an array of 90 ints? Or 200? Do you reject it at
compile time? If so, you have to decide when writing the f *exactly*
how many elements it's going to return; that's far less flexible than
C's current (admittedly unwieldy) mechanisms. Or do you reject it
during execution? If so, how? Do you introduce an exception
mechanism? Do you just say it's undefined behavior? Or do you copy
just part of the array?

Regardless of what syntax you use to express them, arrays are
fundamentally special in ways that other types are not. C's current
way of dealing with that complexity is not pretty, but it works.

Having said all that, you could disallow the assignment and allow
array-returning functions to be used in initializers:

int arr[] = f();

That could probably be quite useful *if* you could manage to define it
without breaking existing code.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

John Bode wrote:
[snip]
> I *suspect* the reason behind the OP's query is that array objects are
> non-modifiable lvalues:
>
> int a[10], b[10];
> b = a; /* illegal! */
>
> Since you can't assign a new array value to an array type object, it
> doesn't make sense to allow functions to return array types. That
> would make it not a mistake in design for no good reason (per Jacob),
> but a consequence of how arrays are handled by the rest of the
> language. Whether "how arrays are handled by the rest of the
> language" is a mistake in design or not is an open issue.

This is just the same for structures. They have to be the same size.

It would be the same for arrays, arrays would be needed to be the same
size.

But then, since size information is always discarded when passing an
array to a function, this would be difficult to achieve.

What I wanted to emphasize is that the whole handling of arrays
is completely crazy in C.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

jacob navia wrote:
>
> What I wanted to emphasize is that the whole handling of arrays
> is completely crazy in C.

Silence your laughter, folks, and remember: This is
the very same Jacob Navia who is only 0.5 Turing Awards
behind Dennis Ritchie himself, who trails Brian Kernighan
by only 0.5 National Medals of Technology, and who has
cut Linus Pauling's once-insurmountable Nobel Prize lead
down to a scant two. It is only a matter of time before
he overtakes Ozymandias.

--
Eric Sosman
esosman@ieee-dot-org.invalid