Why is C not consistent

Take the following two declarations "int arr[3]" and "int *ptr".

Both require different storage, but in usage both are identical. This behaviour  is known, and it is not the consistency I am talking about.

Take the following two declarations:

void funcarr(int a, int arr[3], int c)
{ printf("%d\n", &c-&a); }

void funcptr(int a, int *ptr, int c)
{ printf("%d\n", &c-&a); }

For funcarr, all three arguments are intended to be call by value. So I would expect the stack to contain
a,arr[0],arr[1],arr[2],c
but it does not. The stack contains
a,&arr[0],c

This is *NOT* consistent, and gives a false impression that the elements of arr[] will not change within the lifetime of the function.

Who failed, so I knows whose ass to kick.

dennis ritchie, but he's dead lol. do you wanna kick his corpse?

>>2
Where is he, so I can jump on him instead.

>>3
probably burning in hell!

If you expect a C array to be call-by-value then you are a moron and shouldn't be programming C anyway.

>>5
This is what C-tards actually believe.

That code isn't conforming C code anyway.

Pointer args ARE call by value.  The function gets passed a local copy of an address that it cannot change.

>>7
I know, brackets and indentation wrong.

>>9
No, that's not it.

>>2
PoppaVic from ##C ate him for dinner.

>>1
You did.

>>1
Why on earth would you want to pass an array by-val?

>>13
Why on earth would you want to pass a struct by-val?

wich 2hu would pass by val

>>14
A: You wouldn't.

>>14
In all my years of writing C this is the only point of contention I can see, and it does not affect me much because I always use structure pointers. The same issue comes up with returning structures and structure assignment.

From an implementation perspective it would be simpler to make the programmer do it themselves instead of essentially generating a hidden memcpy(). The latter seems like something closer to C++'s temporary object and hidden constructor/destructor calls.

>>2
dmr has said that the array / pointer interchangeability in function prototypes was inherited from BCPL, and that in retrospect keeping it around was probably a bad idea.  His paper on the development of the C language calls it "a living fossil".

>>1
Both require different storage, but in usage both are identical.

No, they are not.
I see you're one of those faggots who are too stupid to figure out why their programs are being killed for producing segfaults.

>>5
If you expect a C array to be call-by-value then you are a moron and shouldn't be programming C anyway.

Call-by-value is the *only* thing C has. If you think that pointers are pass-by-reference, then please go back to scrubbing toilets, you mental midget. Now only if you'd know what the value of an array is...

protip: an array is not a type

C doesn't have first-class arrays. The names of arrays "decay" to pointers to their first elements. If you want to pass the contents of a fixed-length array by value, you need to put it inside a struct. Fortran, PL/I and ALGOL (all older than C) have first-class arrays and slices. These languages do not provide raw access to memory, so array bounds are stored as part of a hidden "descriptor" and passed to all functions that use the array. The "spirit of C" is not to hide anything from the programmer, so a C array is just a block of memory suitable for that data type. This is one of the reasons why C programs have so many buffer overflows.

>>15
id call fuk(reimu)

>>21
Yes it is.

It's an aggregate type which requires a base type to aggregate on. The same for pointers and structures.

>>24
We learn new things everyday
you can declare structs without fields so no base types
pointers do not require a base type since the base type does not affect it's behavior, it's just for warning issues, an address is an address
arrays default to allocation and a pointer type, it doesn't make sense to use an array in declaration of a parameter unless you want to stress out that it is isn't a pointer to something but actually an array of something:
char ** argv vs char * argv[]

tl;dr: array declaration is pointer declaration with explicit space allocation

>>25
an address is an address
Someone hasn't read the ^C _Standard and thinks x86 is all that's out there.

tl;dr: array declaration is pointer declaration with explicit space allocation
That makes as much sense as saying that int declaration is pointer declaration with explicit space allocation and automatic dereferencing. It's only partially correct and not meaningful.

Here's the most obvious demonstration of the difference between arrays and pointers:

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
    int ar[10];
    int *pt = malloc(10 * sizeof(int));

    printf("sizeof(ar) = %lu\n", sizeof(ar));
    printf("sizeof(pt) = %lu\n", sizeof(pt));

    return 0;
}

>>26

(Post truncated.)
Stopped reading right there

>>26
tl;dr: array declaration is pointer declaration with explicit space allocation
nope

>>25
you can declare structs without fields so no base types
No, that would be equivalent to a base type of void, like a function with no parameters.

pointers do not require a base type since the base type does not affect it's behavior
an address is an address
These are in direct contradiction to each other. If you think only in terms of elements then the former is true but the latter is not, in the context of pointer arithmetic. Similarly if you think in terms of byte (or however wide the memory happens to be) addresses, then the former is false but the latter is true.

>>29
Silly Cudder, since the whitespace is part of your name, would you prefer if people referred to you as "Cudder "? So like, "Silly Cudder enjoys videos of Asian girls in panties" becomes "Silly Cudder  enjoys videos of Asian girls in panties", note the double whitespace after "Cudder" in the latter version.

>>28
A vast majority of the ANSI/ISO C compiler will statically allocate memory for the pointer. However, depending on the type of linkage, the object itself may or many not get created at runtime.

>>28
yup

>>18
This is pretty much the correct answer, although it's due to backwards compatibility with B, not BCPL.

B was the predecessor to C and it didn't have record types (or any types other than ints and arrays.) When you declared an array, e.g. a[5], the compiler created space for six ints: five for the array contents, and one as a pointer to the start of the array. The identifier for an array represented a real pointer in memory. You could actually re-seat the internal storage of arrays in B:

a[5];
b[5];
b = a;

So it made sense that arrays are passed to a functions by reference, because you're not passing the array contents; you're passing the value of the array pointer itself, same as what happens when you assign to an array.

The problem is once they introduced structs, there was no obvious way to initialize the pointer to an array in a struct.

struct foo {
  a[5];
};

If this actually contains six ints, one of which is a pointer to the array, where do we set it? If I malloc() some memory and cast it to a struct foo*, that pointer doesn't get set. So they changed it: the identifier for an array when used in an expression just generates the pointer to the array on the fly. It could no longer be assigned to (because it no longer has storage), but to remain backwards compatible with the existing body of B code, it would still be passed as pointer when used as a function argument.

http://cm.bell-labs.com/who/dmr/chist.html

You could actually re-seat the internal storage of arrays in B:

a[5];
b[5];
b = a;



a[5] and b[5] are *not* arrays, but elements of an array. The distinction is pretty important because one in an umodifiable lvalue while the other one isn'.t

>>33
So it made sense that arrays are passed to a functions by reference

Also, C is pass *by value*, not pass *by reference*.

>>34
No, you misunderstood. The a[5] and b[5] above were declarations of arrays. It would be like writing this in C:

int a[5];
int b[5];

B didn't have type declarations however because it only had one type. Everything was an int. This is why ANSI C has default int.

>>35
Yes, and you're passing by value the pointer to the array. In other words you're passing the array by reference. Way to be uselessly pedantic.

>>35
I just want to rage a bit more about how goddamn fucking stupid your post is. The sentence you cut in half in your quote literally continues "you're passing the value of the array pointer itself".

Your comment is bad and you should feel bad. You are absolute filth, the poison that permeates any decent discussion in programming. You look at an entire comment and pull one sentence fragment out of context, making some trivial pedantic correction to try to appear superior, resulting in zero meaningful contribution to the discussion at hand. Fuck you. Get out.

>>36
No, you misunderstood. The a[5] and b[5] above were declarations of arrays. It would be like writing this in C:

That's not correct you idiot. Sometime like a[5] is an array element. Something like

int a[5]

declares a to be array of 5 integers.
Yes, and you're passing by value the pointer to the array. In other words you're passing the array by reference. Way to be uselessly pedantic.

I'm not being pedantic. A pointer in C and a reference in a language C++ are two distinct beasts. The fact that you mix them up leads me to believe that you've never written any kind of actual code.

>>37
Now let me quote K & R you fucking stupid shit...

"In C, all function arguments are passsed "by value". This means that the called function is given the values of its arguments in temporary variables rather than the originals.  This leads to some different properties than are seen with "call by reference" languages..."

Now shut up and learn somethihng you god damn piece of shit.

>>38
Please learn more programming languages. Pass-by-value and pass-by-reference are broader concepts than int foo(int x); and int bar(int &y);. The meaning is the same in all programming languages even though there happen to be a language construct with the same name in C++.