468,505 Members | 1,790 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,505 developers. It's quick & easy.

why cant functions return arrays

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
Jun 27 '08 #1
127 4144
In article <fd**********************************@1g2000prg.go oglegroups.com>,
sa**************@gmail.com <sa**************@gmail.comwrote:
>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
Jun 27 '08 #2
Walter Roberson wrote:
In article <fd**********************************@1g2000prg.go oglegroups.com>,
sa**************@gmail.com <sa**************@gmail.comwrote:
>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
Jun 27 '08 #3
sa**************@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
Jun 27 '08 #4

"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.cawrote in message
news:fu**********@canopus.cc.umanitoba.ca...
In article
<fd**********************************@1g2000prg.go oglegroups.com>,
sa**************@gmail.com <sa**************@gmail.comwrote:
>>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


Jun 27 '08 #5
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
Jun 27 '08 #6
On Apr 14, 2:25*pm, "sanjay.vasude...@gmail.com"
<sanjay.vasude...@gmail.comwrote:
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.
Jun 27 '08 #7
"Bartc" <bc@freeuk.comwrites:
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.
Jun 27 '08 #8
In article <fu**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:
>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
Jun 27 '08 #9
sa**************@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
Jun 27 '08 #10
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
Jun 27 '08 #11

"Hallvard B Furuseth" <h.**********@usit.uio.nowrote in message
news:hb**************@bombur.uio.no...
sa**************@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


Jun 27 '08 #12
In article <fu**********@aioe.orgja***@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/
Jun 27 '08 #13
In article <4r*****************@text.news.virginmedia.com"Bar tc" <bc@freeuk.comwrites:
....
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/
Jun 27 '08 #14
On Mon, 14 Apr 2008 21:57:20 GMT, "Bartc" <bc@freeuk.comwrote in
comp.lang.c:
>
"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.cawrote in message
news:fu**********@canopus.cc.umanitoba.ca...
In article
<fd**********************************@1g2000prg.go oglegroups.com>,
sa**************@gmail.com <sa**************@gmail.comwrote:
>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
Jun 27 '08 #15
On Mon, 14 Apr 2008 23:55:21 +0200, jacob navia <ja***@nospam.com>
wrote in comp.lang.c:
sa**************@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
Jun 27 '08 #16
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.comwrote:
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;
}

Jun 27 '08 #17
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
es*****@ieee-dot-org.invalid
Jun 27 '08 #18
Bartc writes:
Hallvard B Furuseth" <h.**********@usit.uio.nowrote in message
>news:hb**************@bombur.uio.no...
>sa**************@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
Jun 27 '08 #19
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
Jun 27 '08 #20

"Hallvard B Furuseth" <h.**********@usit.uio.nowrote in message
news:hb**************@bombur.uio.no...
Bartc writes:
Hallvard B Furuseth" <h.**********@usit.uio.nowrote in message
>>news:hb**************@bombur.uio.no...
>>sa**************@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
Jun 27 '08 #21
On Apr 14, 10:01 pm, Jack Klein <jackkl...@spamcop.netwrote:
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.
Jun 27 '08 #22
"sa**************@gmail.com" <sa**************@gmail.comwrites:
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) ks***@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"
Jun 27 '08 #23
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
Jun 27 '08 #24
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
es*****@ieee-dot-org.invalid
Jun 27 '08 #25
On Tue, 15 Apr 2008 12:25:29 -0700 (PDT), John Bode
<jo*******@my-deja.comwrote in comp.lang.c:
On Apr 14, 10:01 pm, Jack Klein <jackkl...@spamcop.netwrote:
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.
In the earliest days of C, you could not do structure assignment,
either. You had to memcpy().

To tell you the truth, I don't think that is as big of an issue as
breaking existing code. This is caused mainly by the interchangeable
use of array names and pointers in expressions, and particularly in
function calls.

Consider:

int ia [10];
int *ip = ia;

....then all of these are valid ways of referring the same int:

*ia; /* looks like ia is a pointer */
ia[0];
*ip;
ip[0];

But the bigger issue, at least prior to prototypes being added by
standardization, was matching function calls to definitions. Look at:

int some_func();

int main()
{
int array [10] = { 0 };
some_func(a);
return 0;
}

In the absence of a prototype declaration (and the sample above with
the non-prototype declaration is legal from K&R all the way through
C99), what gets passed to some_func, a pointer to int or an array of
10 ints?

Since there were no prototypes in K&R, there was no way to inform the
compiler which some_func was actually expecting.

The C89/90 standard could have added passing arrays, classing
functions that received them as requiring correct prototypes in scope
at all calls, under the penalty of undefined behavior. They did that
with variadic functions, and indeed all functions that have arguments
that can't be generated by the default promotions.

But it would have added a feature to the language with difficult
syntax and a great chance of programmer mistakes.

On top of that, the opposite side of the coin is the utility gained by
programmers for all the pain to the implementers.

How useful are assignments, parameters, or return types that are
fixed-size arrays of specific types? That was how Pascal was
originally designed, and it was one of the issues that side tracked
that language until conformant arrays were added to an extended
standard.

--
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
Jun 27 '08 #26
Jack Klein wrote:
>
.... snip ...
>
How useful are assignments, parameters, or return types that are
fixed-size arrays of specific types? That was how Pascal was
originally designed, and it was one of the issues that side tracked
that language until conformant arrays were added to an extended
standard.
Conformant arrays in Pascal do not require ISO10206, (Extended
Pascal). ISO7185 (Standard Pascal) has two levels, 0 and 1, and
level 1 includes conformant arrays. This was the great
standardization hoo-fer-raw back around 1980.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **
Jun 27 '08 #27
In article <fu**********@aioe.orgja***@nospam.org writes:
....
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.
Perhaps it is crazy, but at that time it was a far better solution than
was current in Pascal. (Arrays of different size have a different type,
so it was not possible to write a routine that had as parameter an array
of arbitrary size.)
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Jun 27 '08 #28
Hi guys,

Could anyone please point out what is wrong with my proposed solution.
Please bear with me if my solution sounds incorrect.

On Apr 15, 12:39 pm, Shirsoft <shirs...@gmail.comwrote:
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.comwrote:
>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;

}
Jun 27 '08 #29
Shirsoft wrote:
>
Could anyone please point out what is wrong with my proposed solution.
Please bear with me if my solution sounds incorrect.
One of your primary problems is top-posting. Please do not
top-post. Your answer belongs after (or intermixed with) the
quoted material to which you reply, after snipping all irrelevant
material. See the following links:

<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/ (taming google)
<http://members.fortunecity.com/nnqweb/ (newusers)

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **
Jun 27 '08 #30
"Bartc" <bc@freeuk.comwrites:
>"Hallvard B Furuseth" <h.**********@usit.uio.nowrote in message
news:hb**************@bombur.uio.no...
(...)
>>>>int f()[10];
(...)
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:
If you mean "int *a;", this is a type error (assigning an array to an
int) and I like compilers who warn me about that.

If a is declared as int (*a)[10], fine. That's just a case of allowing
array assignment. You can argue for or against that. Arguments against
is that it can be limited or confusing due to the normal "decay to
pointer" feature, and also that passing an array by value can be a much
huger operation than it looks like when you are used to that what
actually gets passerd is the pointer.
int b[10];
b=f();
Same again.
Or it could be passed directly to another function that takes arrays
of the same size:
g(f());
That may require that the program first copies the array to a temporary
array in the caller's stack. So again, once it's there, what else is
the program allowed to do with the temporary? E.g.:
>Would &f() be OK? *&f()? f()[0]? &f()[0]?
Another point - g(f()) would be an error if a prototype of g() was not
in scope. Then the compiler would not know that g() was expecting
an array rather than a pointer to the first element. So that answers
why it was not in K&R C - it did not have prototypes.

Current C does, but this feature would introduce another point where
calls with and without prototype would differ - and which could not
be fixed by casting the argument to the righe type.
>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.
They wouldn't anyway, due to the problem with g(f()) above. With
regular "decay-to-pointer" arrays, that call works fine with or without
a prototype for g.

Defining this in terms of how functions work is the wrong approach. It
makes things unnecessarily murky.

OTOH with such a non-decaying array type, we'd have that type clearly
spelling out the semantics of such array objects. Which is what types
are _for_. Jacob said he used operator overloading to make such an
array - and unless I misunderstood, what he made was a type.
So setting up dynamic arrays and indexing them as though they were fixed
arrays would not be possible.
I dunno. C99 supports variable-length arrays. But what you are
suggesting also seems to be passing fixed-length arrays around, so I
don't quite see your point.
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.
Yes. There are plenty of features it'd be nice to add to C. The
problem is to choose between them, and to find ten people who agree on
which features would be good and which would be bad. C99 was an attempt
at that, and has been less than successful so far.

--
Hallvard
Jun 27 '08 #31
On 16 Apr 2008 at 13:00, CBFalconer wrote:
One of your primary problems is top-posting.
And one of *your* primary problems is net-nann...

Oh, what's the use?

Jun 27 '08 #32

"CBFalconer" <cb********@yahoo.comwrote in message
news:48***************@yahoo.com...
Shirsoft wrote:
>>
Could anyone please point out what is wrong with my proposed solution.
Please bear with me if my solution sounds incorrect.

One of your primary problems is top-posting. Please do not
top-post.
He's top-posting himself. Special rules apply.

-- Bartc
Jun 27 '08 #33
Bartc wrote:
>
"CBFalconer" <cb********@yahoo.comwrote in message
news:48***************@yahoo.com...
Shirsoft wrote:
>
Could anyone please point out what is wrong with my proposed
solution. Please bear with me if my solution sounds incorrect.
One of your primary problems is top-posting. Please do not
top-post.

He's top-posting himself. Special rules apply.
How do you figure?


Brian
Jun 27 '08 #34

"Default User" <de***********@yahoo.comwrote in message
news:66*************@mid.individual.net...
Bartc wrote:
>>
"CBFalconer" <cb********@yahoo.comwrote in message
news:48***************@yahoo.com...
Shirsoft wrote:

Could anyone please point out what is wrong with my proposed
solution. Please bear with me if my solution sounds incorrect.

One of your primary problems is top-posting. Please do not
top-post.

He's top-posting himself. Special rules apply.

How do you figure?
The fact that Shirsoft top-posted a reply to his own post, or my assertion
about special rules?

The special rules are just my opinion. |After all, someone may have intended
to post ABCD, but first posts BCD then A>BCD, there's not much difference.
But messing around with someone else's article is different.

(And top-posting doesn't bother me in the slightest)

-- Bartc
Jun 27 '08 #35

"Shirsoft" <sh******@gmail.comwrote in message
news:ff**********************************@w8g2000p rd.googlegroups.com...
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.comwrote:
>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?
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;
}
It looks like you allow functions to return (pointers to) arrays of
arbitrary size. In that case you need a mechanism for returning the length
of the array.

If you are pushing around pointers to arrays instead of the arrays
themselves, there might be the problem of memory management when such an
array is modified, destroyed, or goes out of scope; there might be another
pointer to the same array. You are mixing manual memory handling with
automatic handling, that will give problems.

In general C doesn't like hidden or automatic pointers to things, the
language is designed to be transparent. (Although I'm aware there are
extensions that do this sort of thing, and more.)

Your ideas are good. But to implement properly is difficult: a totally new
array type is needed, which is a 3-part value (a,b,c), and it is this value
that is passed around and returned. (a is pointer to the elements, b is the
length, c is some magic required to fix the memory problem). With the
ability to index and so on (and perhaps take slices of, while we're at it!).

It needs a *lot* of compiler support, the arrays take up more space than
regular ones, and could be a little slower. And breaks the rule about
transparency.

-- Bartc

Jun 27 '08 #36
Bartc wrote:
>
"Default User" <de***********@yahoo.comwrote in message
news:66*************@mid.individual.net...
Bartc wrote:
>
"CBFalconer" <cb********@yahoo.comwrote in message
news:48***************@yahoo.com...
Shirsoft wrote:

Could anyone please point out what is wrong with my proposed
solution. Please bear with me if my solution sounds incorrect.

One of your primary problems is top-posting. Please do not
top-post.
>
He's top-posting himself. Special rules apply.
How do you figure?

The fact that Shirsoft top-posted a reply to his own post, or my
assertion about special rules?
Yes.
The special rules are just my opinion. |After all, someone may have
intended to post ABCD, but first posts BCD then A>BCD, there's not
much difference. But messing around with someone else's article is
different.
I'm not following. It doesn't have anything do with "messing around".
The reason for not top-posting is that it makes things difficult to
read, and has lots of unnecessary text. Why was that a special case?


Brian
Jun 27 '08 #37
"Default User" <de***********@yahoo.comwrites:
Bartc wrote:
>>
"Default User" <de***********@yahoo.comwrote in message
news:66*************@mid.individual.net...
Bartc wrote:
"CBFalconer" <cb********@yahoo.comwrote in message
news:48***************@yahoo.com...
Shirsoft wrote:

Could anyone please point out what is wrong with my proposed
solution. Please bear with me if my solution sounds incorrect.

One of your primary problems is top-posting. Please do not
top-post.

He's top-posting himself. Special rules apply.

How do you figure?

The fact that Shirsoft top-posted a reply to his own post, or my
assertion about special rules?

Yes.
>The special rules are just my opinion. |After all, someone may have
intended to post ABCD, but first posts BCD then A>BCD, there's not
much difference. But messing around with someone else's article is
different.

I'm not following. It doesn't have anything do with "messing around".
The reason for not top-posting is that it makes things difficult to
read, and has lots of unnecessary text. Why was that a special case?


Brian
Why do you think people want you to harass and net nanny? You need to
listen to Heathfield - your posts are nothing but noise. You are not in
charge - let people learn by doing. They don't need you providing your
"expertise" in posting techniques. They have "Chuck" for that.

Jun 27 '08 #38


Keith Thompson wrote:
"sa**************@gmail.com" <sa**************@gmail.comwrites:
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?
The following code gives a type mismatch error:
int a[90];
int (*b)[100];
b = &a;

do
>
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) ks***@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"
Jun 27 '08 #39


Keith Thompson wrote:
"sa**************@gmail.com" <sa**************@gmail.comwrites:
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?
The following code gives a type mismatch error:
int a[90];
int (*b)[100];
b = &a;

doesnt this mean that there exists a restriction on array address
assignment based on size.
so, we cud allow functions to return arrays(as a first-class type) of
known size (althogh as u mentioned, this is quite restrictive) and
allow assigning only to same size arrays.

of course "int f()[];" neednt be allowed.

and this treatment as a first-class type would break existing code.

-sanjay
Jun 27 '08 #40
"sa**************@gmail.com" <sa**************@gmail.comwrites:
Keith Thompson wrote:
[...]
>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?

The following code gives a type mismatch error:
int a[90];
int (*b)[100];
b = &a;

doesnt this mean that there exists a restriction on array address
assignment based on size.
Yes. int[90] and int[100] are two distinct types; that's the problem.

It's actually not that much of a problem in C as it currently exists,
because we have other ways of working with arrays of arbitrary length:
we typically work with a pointer to the first element and some
programmer-defined technique of tracking the length. Which means that
it's entirely up to the programmer to make sure array lengths match
when they need to.
so, we cud allow functions to return arrays(as a first-class type) of
known size (althogh as u mentioned, this is quite restrictive) and
allow assigning only to same size arrays.
Right, and IMHO it wouldn't be worth it, because it would be so
inflexible.

<OT>
In Ada, you can declare an array type that leaves the dimensions
unspecified. By specifying the dimensions, you create a *subtype*.
All subtypes of the same type are compile-time compatible, but
operations are checked at run time. The languages operations are
sufficiently powerful (including passing arbitrary arrays as
parameters with full type checking, returning arbitrary arrays from
functions, and a built-in array slicing operation) to make this
workable. I don't believe something like this could be added to C
without altering the feel of the language.
</OT>
of course "int f()[];" neednt be allowed.

and this treatment as a first-class type would break existing code.
Yes.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 27 '08 #41
On Apr 14, 8:01*pm, Jack Klein <jackkl...@spamcop.netwrote:
sanjay.vasude...@gmail.com wrote:
Why are the following declarations invalid in C?
int f()[];
int f()[10];
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.
Of course. The ease with which arrays can be embedded in
structures (and vice versa), as well as the fact that C's
elegant syntax depends on the "peculiar" relationship
of pointer and array means, IMHO, that the views of
OP and Mr. navia imply gross failure to understand and
appreciate C.

As a trivial example, I'm sure I'm not the only one who's
decided to replace, for some "good" reason,
char *foo;
in some context with
char foo[BAZ];
The code which uses foo typically requires almost
no changes! How do you achieve that with Bastardized-C ?

To accept the views of OP and navia we'd have to
agree that changing
int foo[10];
to
struct { int foo[10]; };
is too burdensome for the programmer.
Programmers so easily emburdened would do well
do redirect their queries to
alt.fetish.cobol
or some other ng.language_for_lightweights.

James
Jun 27 '08 #42
Jack Klein <ja*******@spamcop.netwrites:
On Mon, 14 Apr 2008 23:55:21 +0200, jacob navia <ja***@nospam.com>
wrote in comp.lang.c:
>sa**************@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.
So you feel a workaround is a good choice? Nonsense.
Jun 27 '08 #43
James Dow Allen <jd*********@yahoo.comwrites:
On Apr 14, 8:01*pm, Jack Klein <jackkl...@spamcop.netwrote:
sanjay.vasude...@gmail.com wrote:
Why are the following declarations invalid in C?
int f()[];
int f()[10];
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.

Of course. The ease with which arrays can be embedded in
structures (and vice versa), as well as the fact that C's
elegant syntax depends on the "peculiar" relationship
of pointer and array means, IMHO, that the views of
OP and Mr. navia imply gross failure to understand and
appreciate C.
"Mr Navia". Someone is setting Heathfield up here.
>
As a trivial example, I'm sure I'm not the only one who's
decided to replace, for some "good" reason,
char *foo;
in some context with
char foo[BAZ];
The code which uses foo typically requires almost
no changes! How do you achieve that with Bastardized-C ?
Bastardized C? Where did Jacob suggest bastardized anything? Possibly
you're referring to Klein's wrapping array in a struct solution?
>
To accept the views of OP and navia we'd have to
agree that changing
int foo[10];
to
struct { int foo[10]; };
is too burdensome for the programmer.
Where does this end? You seem to to think that any form of ugly kludge
is OK when used to put Jacob down.
Programmers so easily emburdened would do well
This post has Heathfield sockpuppet written all over it.
do redirect their queries to
alt.fetish.cobol
or some other ng.language_for_lightweights.

James
Or maybe alt.religious.idiot ?
Jun 27 '08 #44
James Dow Allen wrote:
On Apr 14, 8:01 pm, Jack Klein <jackkl...@spamcop.netwrote:
>>sanjay.vasude...@gmail.com wrote:
Why are the following declarations invalid in C?
int f()[];
int f()[10];
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.

Of course. The ease with which arrays can be embedded in
structures (and vice versa), as well as the fact that C's
elegant syntax depends on the "peculiar" relationship
of pointer and array means, IMHO, that the views of
OP and Mr. navia imply gross failure to understand and
appreciate C.

As a trivial example, I'm sure I'm not the only one who's
decided to replace, for some "good" reason,
char *foo;
in some context with
char foo[BAZ];
The code which uses foo typically requires almost
no changes! How do you achieve that with Bastardized-C ?
This is precisely the problem.
Since you can do easily this kind of hack, size information
must be discarded when passing an array into another function.

#include <stdio.h>
int fn(int tab[45])
{
printf("sizeof(tab)=%d\n",sizeof(tab));
}

int main(void) { int tab[45]; fn(tab); }

I get sizeof(tab) =4

I get the size of a int pointer, even if I explicitely
specified the size of the array.

This makes checking array bounds impossible in C.
To accept the views of OP and navia we'd have to
agree that changing
int foo[10];
to
struct { int foo[10]; };
This will not even compile!
You missed the name of the structure. You have to give
a name to all the different array sizes!
is too burdensome for the programmer.
Programmers so easily emburdened would do well
do redirect their queries to
alt.fetish.cobol
or some other ng.language_for_lightweights.
This arrogant point of view tries to sell us a work
around as a feature.

And obviously it is *SO EASY* that geniuses like you
can't get it right! :-)

James

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jun 27 '08 #45
On Sun, 20 Apr 2008 13:44:09 +0200, Richard <de***@gmail.com>
wrote:
>James Dow Allen <jd*********@yahoo.comwrites:
>This post has Heathfield sockpuppet written all over it.
Please drop the Heathfield sockpuppet schtick; it's silly. James
Dow Allen is a well known usenet personality. Just because
someone writes something vaguely similar to something Heathfield
might write doesn't make them a Heathfield sockpuppet.
Richard Harter, cr*@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.
Jun 27 '08 #46
Richard Harter said:
On Sun, 20 Apr 2008 13:44:09 +0200, Richard <de***@gmail.com>
wrote:
>>James Dow Allen <jd*********@yahoo.comwrites:
>>This post has Heathfield sockpuppet written all over it.

Please drop the Heathfield sockpuppet schtick; it's silly.
It's also a lie. I don't do sockpuppetry.
James
Dow Allen is a well known usenet personality. Just because
someone writes something vaguely similar to something Heathfield
might write doesn't make them a Heathfield sockpuppet.
The problem faced by Richard Riley and his fellow trolls is that a lot of
articles posted in this newsgroup express opinions similar to mine. There
are only two ways to explain this - either I'm using a great number of
sock puppets, or there are a lot of people in this newsgroup who very
often agree with what I write. It seems that the trolls cannot bring
themselves to believe the latter, so they are forced to assume the former,
in defiance of the facts. Their problem, not mine.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jun 27 '08 #47
In article <jJ******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote a bunch of his usual
nonsense:
>The problem faced by Richard Riley and his fellow trolls is that a lot of
articles posted in this newsgroup express opinions similar to mine. There
Or you're just lying. Occam's razor, and all that.

Jun 27 '08 #48
ga*****@xmission.xmission.com (Kenny McCormack) writes:
In article <jJ******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote a bunch of his usual
nonsense:
>>The problem faced by Richard Riley and his fellow trolls is that a lot of
articles posted in this newsgroup express opinions similar to mine. There

Or you're just lying. Occam's razor, and all that.
And a lot of people blatantly do not agree with Heathfield who is, to be
honest, so full of himself I am astonished his head can fit through the
door. It's funny how one is a troll when one says "Hey, there's no need
to be so rude and obnoxious". He appears to have made a career out of
it though from what I can gather in this group. A more thoroughly
unpleasant character would be hard to pinpoint in this or other
technical news groups.

Jun 27 '08 #49
Hello List

Not particulary to anyone, but...

Any possibility to change the standard and return arrays? If yes, what
is the path to accomplish that? If no, what is the purpose of this
thread? Global trolling? Some place to put everything off? If yes,
please, call-me back here asap. I have a lot to say too.

Regards
Rafael
Jun 27 '08 #50

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.