Why would someone put a lonely array inside a structure?

struct ip_address { unsigned char d[4]; };

Would it be because they want to (in the future) add more members to
this structure? Because it's not like they can hide this array in the
structure; it's still referenced as

struct ip_address ip;
ip.d[0] = ...
ip.d[1] = ...

But it does look neat, so I guess neatness is the reason? It's also
easier to read because we're constantly reminded it is an ip address?

Le 12/11/2021 à 19:48, Meredith Montgomery a écrit :
> Why would someone put a lonely array inside a structure?
>
> struct ip_address { unsigned char d[4]; };
>
> Would it be because they want to (in the future) add more members to
> this structure?

That can be a good reason. Anticipating makes for much more maintainable
code.

But another reason here is that it's a way to make it possible to copy
arrays. In C, you can't copy arrays.

unsigned char d1[4], d2[4];

d2 = d1; // invalid C

You have to either copy item by item in a loop, or use memcpy() or
something similar.

If you encapsulate an array in a struct, now you can do it more elegantly:

struct ip_address ip1, ip2;

ip2 = ip1; // perfectly valid C, and will copy the whole array

Of course, if you add members to the struct, it still works and will
copy all members.

Guillaume <message@bottle.org> writes:

> Le 12/11/2021 à 19:48, Meredith Montgomery a écrit :
>> Why would someone put a lonely array inside a structure?
>> struct ip_address { unsigned char d[4]; };
>> Would it be because they want to (in the future) add more members to
>> this structure?
>
> That can be a good reason. Anticipating makes for much more maintainable code.
>
> But another reason here is that it's a way to make it possible to copy
> arrays. In C, you can't copy arrays.
>
> unsigned char d1[4], d2[4];
>
> d2 = d1; // invalid C
>
> You have to either copy item by item in a loop, or use memcpy() or
> something similar.
>
> If you encapsulate an array in a struct, now you can do it more elegantly:
>
> struct ip_address ip1, ip2;
>
> ip2 = ip1; // perfectly valid C, and will copy the whole array

And a special case of copying is passing values to a function. That
might even be the /main/ reason for putting an array into a struct,
though only the code's author really knows.

--
Ben.

On 12/11/2021 20:31, Ben Bacarisse wrote:
> Guillaume <message@bottle.org> writes:
>
>> Le 12/11/2021 à 19:48, Meredith Montgomery a écrit :
>>> Why would someone put a lonely array inside a structure?
>>> struct ip_address { unsigned char d[4]; };
>>> Would it be because they want to (in the future) add more members to
>>> this structure?
>>
>> That can be a good reason. Anticipating makes for much more maintainable code.
>>
>> But another reason here is that it's a way to make it possible to copy
>> arrays. In C, you can't copy arrays.
>>
>> unsigned char d1[4], d2[4];
>>
>> d2 = d1; // invalid C
>>
>> You have to either copy item by item in a loop, or use memcpy() or
>> something similar.
>>
>> If you encapsulate an array in a struct, now you can do it more elegantly:
>>
>> struct ip_address ip1, ip2;
>>
>> ip2 = ip1; // perfectly valid C, and will copy the whole array
>
> And a special case of copying is passing values to a function. That
> might even be the /main/ reason for putting an array into a struct,
> though only the code's author really knows.
>

That is certainly one reason why I do it. Basically, it means you have
a "value" type that does not decay to a pointer. It also means the size
is fixed and available via "sizeof" as it is passed around, and perhaps
most importantly it is a specific type. The "struct ip_address" here is
a named type that cannot be confused with any other array of unsigned
char, nor a pointer to an unsigned char.

On Fri, 2021-11-12, Meredith Montgomery wrote:
> Why would someone put a lonely array inside a structure?
>
> struct ip_address { unsigned char d[4]; };

Or the official Unix IPv6 address:

struct in6_addr {
unsigned char s6_addr[16]; /* IPv6 address */
};

> Would it be because they want to (in the future) add more members to
> this structure?

Not in this case -- noone will ever change the definition of "an IPv4
address". I hope.

> Because it's not like they can hide this array in the
> structure; it's still referenced as
>
> struct ip_address ip;
> ip.d[0] = ...
> ip.d[1] = ...
>
> But it does look neat, so I guess neatness is the reason? It's also
> easier to read because we're constantly reminded it is an ip address?

Others have already replied; I will give a similar answer.

I use this pattern all the time, whenever I can, i.e. when it's ok that
all arrays are the same length[0]. The benefits are:

- I get a real, distinct type with a name, which doesn't convert or
decay to other types. struct in6_addr isn't just /any/ array of 16
unsigned chars: it's an IPv6 address.

- I get objects which work like any other objects in assignments,
function calls and so on.

There is no information hiding, but that's not a big problem IMO. Or
perhaps I have gotten used to it.

/Jorgen

[0] And when the length is variable you can sometimes do

struct foo {
struct bar v[31];
unsigned count;
};

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Le 13/11/2021 à 09:47, Jorgen Grahn a écrit :
> On Fri, 2021-11-12, Meredith Montgomery wrote:
>> Because it's not like they can hide this array in the
>> structure; it's still referenced as
(...)
> There is no information hiding, but that's not a big problem IMO. Or
> perhaps I have gotten used to it.

Actually, I didn't mention it, but encapsulating data in a struct does
allow some form of "information hiding" - if we all mean the same thing
here.

You can define "opaque" types using structs - more precisely, using
pointers to structs. It's commonly seen in standard libraries, POSIX
stuff, etc.

Of course, if you have access to the struct definition, there is no
hiding per se, but you can absolutely distribute a library with only
opaque data types for the user of the library.

'FILE *' is a common example. Do you ever care what is behind a FILE
type? It often depends on the platform anyway. You only use it through a
pointer.

What allows to hide what's inside a struct in C using pointers is the
fact you can absolutely define a pointer to a struct without defining
the struct itself:

typedef struct Foo * Foo_t;

As long as you don't need to directly access the underlying struct
members, that works plenty fine - typical use is through function calls.

On 2021-11-12, Meredith Montgomery <mmontgomery@levado.to> wrote:
> Why would someone put a lonely array inside a structure?
>
> struct ip_address { unsigned char d[4]; };

The main reason is because structs provide more abstraction than
arrays in C.

You can assign them, pass them into functions and return them.

If you have

typedef struct ip_address ip_address_t;

this ip_address_t type will not do weird things, like if it were an
array typedef; it will not turn into a pointer when you use it to
declare a function parameter, or produce object definitions that
cannot be assigned.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

Il 12/11/2021 21:07, David Brown ha scritto:
> On 12/11/2021 20:31, Ben Bacarisse wrote:
>> Guillaume <message@bottle.org> writes:
>>
>>> Le 12/11/2021 à 19:48, Meredith Montgomery a écrit :
>>>> Why would someone put a lonely array inside a structure?
>>>> struct ip_address { unsigned char d[4]; };
>>>> Would it be because they want to (in the future) add more members to
>>>> this structure?
>>>
>>> That can be a good reason. Anticipating makes for much more maintainable code.
>>>
>>> But another reason here is that it's a way to make it possible to copy
>>> arrays. In C, you can't copy arrays.
>>>
>>> unsigned char d1[4], d2[4];
>>>
>>> d2 = d1; // invalid C
>>>
>>> You have to either copy item by item in a loop, or use memcpy() or
>>> something similar.
>>>
>>> If you encapsulate an array in a struct, now you can do it more elegantly:
>>>
>>> struct ip_address ip1, ip2;
>>>
>>> ip2 = ip1; // perfectly valid C, and will copy the whole array
>>
>> And a special case of copying is passing values to a function. That
>> might even be the /main/ reason for putting an array into a struct,
>> though only the code's author really knows.
>>
>
> That is certainly one reason why I do it. Basically, it means you have
> a "value" type that does not decay to a pointer. It also means the size
> is fixed and available via "sizeof" as it is passed around, and perhaps
> most importantly it is a specific type. The "struct ip_address" here is
> a named type that cannot be confused with any other array of unsigned
> char, nor a pointer to an unsigned char.
>

Regarding your two last sentences, the same can be achieved with:

typedef unsigned char ip_address[4];

So I don't think those two last arguments are the real reason to embed a
fixed-sized array into a struct.

On 18/11/2021 15:53, pozz wrote:
> Il 12/11/2021 21:07, David Brown ha scritto:
>> On 12/11/2021 20:31, Ben Bacarisse wrote:
>>> Guillaume <message@bottle.org> writes:
>>>
>>>> Le 12/11/2021 à 19:48, Meredith Montgomery a écrit :
>>>>> Why would someone put a lonely array inside a structure?
>>>>>     struct ip_address { unsigned char d[4]; };
>>>>> Would it be because they want to (in the future) add more members to
>>>>> this structure?
>>>>
>>>> That can be a good reason. Anticipating makes for much more
>>>> maintainable code.
>>>>
>>>> But another reason here is that it's a way to make it possible to copy
>>>> arrays. In C, you can't copy arrays.
>>>>
>>>> unsigned char d1[4], d2[4];
>>>>
>>>> d2 = d1; // invalid C
>>>>
>>>> You have to either copy item by item in a loop, or use memcpy() or
>>>> something similar.
>>>>
>>>> If you encapsulate an array in a struct, now you can do it more
>>>> elegantly:
>>>>
>>>> struct ip_address ip1, ip2;
>>>>
>>>> ip2 = ip1; // perfectly valid C, and will copy the whole array
>>>
>>> And a special case of copying is passing values to a function.  That
>>> might even be the /main/ reason for putting an array into a struct,
>>> though only the code's author really knows.
>>>
>>
>> That is certainly one reason why I do it.  Basically, it means you have
>> a "value" type that does not decay to a pointer.  It also means the size
>> is fixed and available via "sizeof" as it is passed around, and perhaps
>> most importantly it is a specific type.  The "struct ip_address" here is
>> a named type that cannot be confused with any other array of unsigned
>> char, nor a pointer to an unsigned char.
>>
>
> Regarding your two last sentences, the same can be achieved with:
>
>   typedef unsigned char ip_address[4];
>
> So I don't think those two last arguments are the real reason to embed a
> fixed-sized array into a struct.
>

No, it is not the same thing at all.

Try compiling:

typedef unsigned char ip_address[4];
ip_address a;
unsigned char * p = a;

Since "a" is just an array of unsigned char, most uses of it in an
expression decay to a pointer to the first element. "typedef", despite
the name, does not define a type - it gives an alias to an existing
type. If you want to make a new type so that pointers to it are
incompatible with other pointer types, you need to put it in a struct
(or a union, but that might seem a little odd). And wrapping it in a
struct (or union) is the only way to stop this decay, so that the type
retains its value and size even when passed into and out of functions.

On 11/18/2021 4:13 PM, David Brown wrote:
> On 18/11/2021 15:53, pozz wrote:
>> Il 12/11/2021 21:07, David Brown ha scritto:
>>> On 12/11/2021 20:31, Ben Bacarisse wrote:
>>>> Guillaume <message@bottle.org> writes:
>>>>
>>>>> Le 12/11/2021 à 19:48, Meredith Montgomery a écrit :
>>>>>> Why would someone put a lonely array inside a structure?
>>>>>>     struct ip_address { unsigned char d[4]; };
>>>>>> Would it be because they want to (in the future) add more members to
>>>>>> this structure?
>>>>>
>>>>> That can be a good reason. Anticipating makes for much more
>>>>> maintainable code.
>>>>>
>>>>> But another reason here is that it's a way to make it possible to copy
>>>>> arrays. In C, you can't copy arrays.
>>>>>
>>>>> unsigned char d1[4], d2[4];
>>>>>
>>>>> d2 = d1; // invalid C
>>>>>
>>>>> You have to either copy item by item in a loop, or use memcpy() or
>>>>> something similar.
>>>>>
>>>>> If you encapsulate an array in a struct, now you can do it more
>>>>> elegantly:
>>>>>
>>>>> struct ip_address ip1, ip2;
>>>>>
>>>>> ip2 = ip1; // perfectly valid C, and will copy the whole array
>>>>
>>>> And a special case of copying is passing values to a function.  That
>>>> might even be the /main/ reason for putting an array into a struct,
>>>> though only the code's author really knows.
>>>>
>>>
>>> That is certainly one reason why I do it.  Basically, it means you have
>>> a "value" type that does not decay to a pointer.  It also means the size
>>> is fixed and available via "sizeof" as it is passed around, and perhaps
>>> most importantly it is a specific type.  The "struct ip_address" here is
>>> a named type that cannot be confused with any other array of unsigned
>>> char, nor a pointer to an unsigned char.
>>>
>>
>> Regarding your two last sentences, the same can be achieved with:
>>
>>   typedef unsigned char ip_address[4];
>>
>> So I don't think those two last arguments are the real reason to embed a
>> fixed-sized array into a struct.
>>
>
> No, it is not the same thing at all.
>
>
> Try compiling:
>
> typedef unsigned char ip_address[4];
> ip_address a;
> unsigned char * p = a;
>
> Since "a" is just an array of unsigned char, most uses of it in an
> expression decay to a pointer to the first element. "typedef", despite
> the name, does not define a type - it gives an alias to an existing
> type. If you want to make a new type so that pointers to it are
> incompatible with other pointer types, you need to put it in a struct
> (or a union, but that might seem a little odd). And wrapping it in a
> struct (or union) is the only way to stop this decay, so that the type
> retains its value and size even when passed into and out of functions.
>

Even more:

$ cat ip_address_array_size.c
#include <stdio.h>

typedef unsigned char ip_address[4];

void foo(ip_address a)
{ printf("sizeof(a) = %zu\n", sizeof(a)); // sizeof(a) returns
sizeof(unsigned char*)
}

int main(void)
{ unsigned char a[] = { 1, 2, 3, 4 };

foo(a); // unsigned char[4] is valid here
}

$ gcc -std=c11 -O2 -Wall -Wextra ip_address_array_size.c && ./a.out
ip_address_array_size.c: In function ‘foo’:
ip_address_array_size.c:7:37: warning: ‘sizeof’ on array function
parameter ‘a’ will return size of ‘unsigned char *’
[-Wsizeof-array-argument]
7 | printf("sizeof(a) = %zu\n", sizeof(a)); // sizeof(a) returns
sizeof(unsigned char*)
| ^
ip_address_array_size.c:5:21: note: declared here
5 | void foo(ip_address a)
| ~~~~~~~~~~~^
sizeof(a) = 8

Il 18/11/2021 16:26, Manfred ha scritto:
> On 11/18/2021 4:13 PM, David Brown wrote:
>> On 18/11/2021 15:53, pozz wrote:
>>> Il 12/11/2021 21:07, David Brown ha scritto:
>>>> On 12/11/2021 20:31, Ben Bacarisse wrote:
>>>>> Guillaume <message@bottle.org> writes:
>>>>>
>>>>>> Le 12/11/2021 à 19:48, Meredith Montgomery a écrit :
>>>>>>> Why would someone put a lonely array inside a structure?
>>>>>>>      struct ip_address { unsigned char d[4]; };
>>>>>>> Would it be because they want to (in the future) add more members to
>>>>>>> this structure?
>>>>>>
>>>>>> That can be a good reason. Anticipating makes for much more
>>>>>> maintainable code.
>>>>>>
>>>>>> But another reason here is that it's a way to make it possible to
>>>>>> copy
>>>>>> arrays. In C, you can't copy arrays.
>>>>>>
>>>>>> unsigned char d1[4], d2[4];
>>>>>>
>>>>>> d2 = d1; // invalid C
>>>>>>
>>>>>> You have to either copy item by item in a loop, or use memcpy() or
>>>>>> something similar.
>>>>>>
>>>>>> If you encapsulate an array in a struct, now you can do it more
>>>>>> elegantly:
>>>>>>
>>>>>> struct ip_address ip1, ip2;
>>>>>>
>>>>>> ip2 = ip1; // perfectly valid C, and will copy the whole array
>>>>>
>>>>> And a special case of copying is passing values to a function.  That
>>>>> might even be the /main/ reason for putting an array into a struct,
>>>>> though only the code's author really knows.
>>>>>
>>>>
>>>> That is certainly one reason why I do it.  Basically, it means you have
>>>> a "value" type that does not decay to a pointer.  It also means the
>>>> size
>>>> is fixed and available via "sizeof" as it is passed around, and perhaps
>>>> most importantly it is a specific type.  The "struct ip_address"
>>>> here is
>>>> a named type that cannot be confused with any other array of unsigned
>>>> char, nor a pointer to an unsigned char.
>>>>
>>>
>>> Regarding your two last sentences, the same can be achieved with:
>>>
>>>    typedef unsigned char ip_address[4];
>>>
>>> So I don't think those two last arguments are the real reason to embed a
>>> fixed-sized array into a struct.
>>>
>>
>> No, it is not the same thing at all.
>>
>>
>> Try compiling:
>>
>>     typedef unsigned char ip_address[4];
>>     ip_address a;
>>     unsigned char * p = a;
>>
>> Since "a" is just an array of unsigned char, most uses of it in an
>> expression decay to a pointer to the first element.  "typedef", despite
>> the name, does not define a type - it gives an alias to an existing
>> type.  If you want to make a new type so that pointers to it are
>> incompatible with other pointer types, you need to put it in a struct
>> (or a union, but that might seem a little odd).  And wrapping it in a
>> struct (or union) is the only way to stop this decay, so that the type
>> retains its value and size even when passed into and out of functions.
>>
>
> Even more:
>
>
> $ cat ip_address_array_size.c
> #include <stdio.h>
>
> typedef unsigned char ip_address[4];
>
> void foo(ip_address a)
> {
>   printf("sizeof(a) = %zu\n", sizeof(a)); // sizeof(a) returns
> sizeof(unsigned char*)
> }
>
> int main(void)
> {
>   unsigned char a[] = { 1, 2, 3, 4 };
>
>   foo(a); // unsigned char[4] is valid here
> }
>
> $ gcc -std=c11 -O2 -Wall -Wextra ip_address_array_size.c && ./a.out
> ip_address_array_size.c: In function ‘foo’:
> ip_address_array_size.c:7:37: warning: ‘sizeof’ on array function
> parameter ‘a’ will return size of ‘unsigned char *’
> [-Wsizeof-array-argument]
>     7 |   printf("sizeof(a) = %zu\n", sizeof(a)); // sizeof(a) returns
> sizeof(unsigned char*)
>       |                                     ^
> ip_address_array_size.c:5:21: note: declared here
>     5 | void foo(ip_address a)
>       |          ~~~~~~~~~~~^
> sizeof(a) = 8

Ok, my shame, you're right.

Next time I will think twice before repling.

On 11/18/2021 5:22 PM, pozz wrote:
> Il 18/11/2021 16:26, Manfred ha scritto:
>> On 11/18/2021 4:13 PM, David Brown wrote:
>>> On 18/11/2021 15:53, pozz wrote:
>>>> Il 12/11/2021 21:07, David Brown ha scritto:
>>>>> On 12/11/2021 20:31, Ben Bacarisse wrote:
>>>>>> Guillaume <message@bottle.org> writes:
>>>>>>
>>>>>>> Le 12/11/2021 à 19:48, Meredith Montgomery a écrit :
>>>>>>>> Why would someone put a lonely array inside a structure?
>>>>>>>>      struct ip_address { unsigned char d[4]; };
>>>>>>>> Would it be because they want to (in the future) add more
>>>>>>>> members to
>>>>>>>> this structure?
>>>>>>>
>>>>>>> That can be a good reason. Anticipating makes for much more
>>>>>>> maintainable code.
>>>>>>>
>>>>>>> But another reason here is that it's a way to make it possible to
>>>>>>> copy
>>>>>>> arrays. In C, you can't copy arrays.
>>>>>>>
>>>>>>> unsigned char d1[4], d2[4];
>>>>>>>
>>>>>>> d2 = d1; // invalid C
>>>>>>>
>>>>>>> You have to either copy item by item in a loop, or use memcpy() or
>>>>>>> something similar.
>>>>>>>
>>>>>>> If you encapsulate an array in a struct, now you can do it more
>>>>>>> elegantly:
>>>>>>>
>>>>>>> struct ip_address ip1, ip2;
>>>>>>>
>>>>>>> ip2 = ip1; // perfectly valid C, and will copy the whole array
>>>>>>
>>>>>> And a special case of copying is passing values to a function.  That
>>>>>> might even be the /main/ reason for putting an array into a struct,
>>>>>> though only the code's author really knows.
>>>>>>
>>>>>
>>>>> That is certainly one reason why I do it.  Basically, it means you
>>>>> have
>>>>> a "value" type that does not decay to a pointer.  It also means the
>>>>> size
>>>>> is fixed and available via "sizeof" as it is passed around, and
>>>>> perhaps
>>>>> most importantly it is a specific type.  The "struct ip_address"
>>>>> here is
>>>>> a named type that cannot be confused with any other array of unsigned
>>>>> char, nor a pointer to an unsigned char.
>>>>>
>>>>
>>>> Regarding your two last sentences, the same can be achieved with:
>>>>
>>>>    typedef unsigned char ip_address[4];
>>>>
>>>> So I don't think those two last arguments are the real reason to
>>>> embed a
>>>> fixed-sized array into a struct.
>>>>
>>>
>>> No, it is not the same thing at all.
>>>
>>>
>>> Try compiling:
>>>
>>>     typedef unsigned char ip_address[4];
>>>     ip_address a;
>>>     unsigned char * p = a;
>>>
>>> Since "a" is just an array of unsigned char, most uses of it in an
>>> expression decay to a pointer to the first element.  "typedef", despite
>>> the name, does not define a type - it gives an alias to an existing
>>> type.  If you want to make a new type so that pointers to it are
>>> incompatible with other pointer types, you need to put it in a struct
>>> (or a union, but that might seem a little odd).  And wrapping it in a
>>> struct (or union) is the only way to stop this decay, so that the type
>>> retains its value and size even when passed into and out of functions.
>>>
>>
>> Even more:
>>
>>
>> $ cat ip_address_array_size.c
>> #include <stdio.h>
>>
>> typedef unsigned char ip_address[4];
>>
>> void foo(ip_address a)
>> {
>>    printf("sizeof(a) = %zu\n", sizeof(a)); // sizeof(a) returns
>> sizeof(unsigned char*)
>> }
>>
>> int main(void)
>> {
>>    unsigned char a[] = { 1, 2, 3, 4 };
>>
>>    foo(a); // unsigned char[4] is valid here
>> }
>>
>> $ gcc -std=c11 -O2 -Wall -Wextra ip_address_array_size.c && ./a.out
>> ip_address_array_size.c: In function ‘foo’:
>> ip_address_array_size.c:7:37: warning: ‘sizeof’ on array function
>> parameter ‘a’ will return size of ‘unsigned char *’
>> [-Wsizeof-array-argument]
>>      7 |   printf("sizeof(a) = %zu\n", sizeof(a)); // sizeof(a)
>> returns sizeof(unsigned char*)
>>        |                                     ^
>> ip_address_array_size.c:5:21: note: declared here
>>      5 | void foo(ip_address a)
>>        |          ~~~~~~~~~~~^
>> sizeof(a) = 8
>
> Ok, my shame, you're right.
>
> Next time I will think twice before repling.

No shame, no problem.
Posts like this give a chance to clarify doubts to other readers as well.

On 18/11/2021 17:22, pozz wrote:
>
> Ok, my shame, you're right.
>
> Next time I will think twice before repling.

It is a well-known fact that the best way to get an answer on the
internet is not to post a question, but to post the wrong answer!

Arrays and typedefs can be subtle things in C, and are easily
misunderstood - they can seem to work the way you want to start with,
but other things happen when they get passed around via pointers and
function parameters. It is good to question it like you did - that's
how you learn, and can also aid others in learning. There is never a
shame in asking a (topical :-) ) question here, nor in making a mistake
and getting corrected. There's only a shame in not asking when you are
not sure, or not accepting it when a mistake is corrected.

Meredith Montgomery:

> Why would someone put a lonely array inside a structure?
>
> struct ip_address { unsigned char d[4]; };

Here is a comment on that matter from the maintainer of the
Netpbm project. This is from a private e-mail, but I hope he
will not object to publishing of this quotation:

And one somewhat more substantial thing: t_float3
(Float3) should be a struct containing a double[] rather
than just a double[]. That way you don't have confusing
degeneration to a pointer when you pass it to a function
and it becomes obvious what the outputs of a function are
(because they're explicit pointers to the struct).

--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]

Le 18/11/2021 à 22:58, David Brown a écrit :
> It is a well-known fact that the best way to get an answer on the
> internet is not to post a question, but to post the wrong answer!

Very true! :D

> Arrays and typedefs can be subtle things in C, and are easily
> misunderstood - they can seem to work the way you want to start with,
> but other things happen when they get passed around via pointers and
> function parameters.

Well arrays in C are not so subtle, but they can be surprising,
especially for beginners.

You raise two points here:

1. Arrays are compatible with pointers of the same base type, but since
C pointers are dumb things that are nothing like "fat" pointers, they
can't possibly hold any other attribute than a memory location. Thus,
obviously a pointer can't hold the 'size' of the pointed location. So
this point should not be particularly confusing, even to beginners. In
particular, sizeof of a pointer is nothing else than the size of the
pointer itself. Always. What you assign to the pointer doesn's matter,
even if it's an array.

Now there are kind of exceptions to that, but that are purely
"hand-implemented" and have nothing to do with the language itself: for
instance, the typical malloc() behavior. Behind the scenes, pointers
returned by malloc() are "fat pointers", and you can also implement your
own fat pointers if you so wish. But the language doesn't care. It has
no provision for that, except you can do pointer arithmetics to your
heart's content.

2. The second point is less well known and admittedly a lot more
confusing. A function parameter can be an array type, but in this
particular context, sizeof can't get the size either. That part IS
definitely confusing, and doesn't make much sense IMHO, but it has
legacy reasons. Fortunately, decent compilers warn about it, but that
helps only those who care to read warnings. Which anyone should anyway.

For this second point, I'm not sure it's strictly a problem about arrays
in C rather than a "problem" with function arguments. Now that
distinction is subtle indeed.

Manfred <noname@add.invalid> writes:

[...]

>> Ok, my shame, you're right.
>> Next time I will think twice before repling.
>
> No shame, no problem.
> Posts like this give a chance to clarify doubts to other readers as well.

So true!

Anton Shepelev <anton.txt@g{oogle}mail.com> writes:

> Meredith Montgomery:
>
>> Why would someone put a lonely array inside a structure?
>>
>> struct ip_address { unsigned char d[4]; };
>
> Here is a comment on that matter from the maintainer of the
> Netpbm project. This is from a private e-mail, but I hope he
> will not object to publishing of this quotation:
>
> And one somewhat more substantial thing: t_float3
> (Float3) should be a struct containing a double[] rather
> than just a double[]. That way you don't have confusing
> degeneration to a pointer when you pass it to a function
> and it becomes obvious what the outputs of a function are
> (because they're explicit pointers to the struct).

Interesting. That seems point 2 written in Message-ID

<sn8kq9$tep$1@gioia.aioe.org>

Thanks for sharing.

Guillaume <message@bottle.org> writes:
> Le 18/11/2021 à 22:58, David Brown a écrit :
>> It is a well-known fact that the best way to get an answer on the
>> internet is not to post a question, but to post the wrong answer!
>
> Very true! :D
>
>> Arrays and typedefs can be subtle things in C, and are easily
>> misunderstood - they can seem to work the way you want to start with,
>> but other things happen when they get passed around via pointers and
>> function parameters.
>
> Well arrays in C are not so subtle, but they can be surprising,
> especially for beginners.

The best explanation I've seen of the often confusing relationship
between arrays and pointers in C is section 6 of the comp.lang.c FAQ:
http://www.c-faq.com/

> You raise two points here:
>
> 1. Arrays are compatible with pointers of the same base type, but
> since C pointers are dumb things that are nothing like "fat" pointers,
> they can't possibly hold any other attribute than a memory
> location. Thus, obviously a pointer can't hold the 'size' of the
> pointed location. So this point should not be particularly confusing,
> even to beginners. In particular, sizeof of a pointer is nothing else
> than the size of the pointer itself. Always. What you assign to the
> pointer doesn's matter, even if it's an array.

Arrays are not "compatible" with pointers. C has a well defined concept
of type compatibility. It doesn't refer to types that can be assigned
to each other.

Every pointer value refers to a memory address *and* (other than void*)
specifies the type of the object it points to . That type information
includes the size of the target type. The size information isn't
contained in the pointer object, any more than an int object contains
the value of sizeof (int). A pointer to an *element* of an array object
doesn't tell us the size of the array object.

> Now there are kind of exceptions to that, but that are purely
> "hand-implemented" and have nothing to do with the language itself:
> for instance, the typical malloc() behavior. Behind the scenes,
> pointers returned by malloc() are "fat pointers", and you can also
> implement your own fat pointers if you so wish. But the language
> doesn't care. It has no provision for that, except you can do pointer
> arithmetics to your heart's content.

I'm not sure what you mean about malloc() returning "fat pointers".
malloc() returns a void* with no information about the size or type of
what it points to. Some implementations might provide a way to query
the size of the allocated space, but that's not standard.

> 2. The second point is less well known and admittedly a lot more
> confusing. A function parameter can be an array type, but in this
> particular context, sizeof can't get the size either. That part IS
> definitely confusing, and doesn't make much sense IMHO, but it has
> legacy reasons. Fortunately, decent compilers warn about it, but that
> helps only those who care to read warnings. Which anyone should
> anyway.
>
> For this second point, I'm not sure it's strictly a problem about
> arrays in C rather than a "problem" with function arguments. Now that
> distinction is subtle indeed.

There are two basic rules to remember.

First, an expression of array type is, in most contexts, "converted" to
a pointer expression whose value points to the initial element of the
array object. (This is a compile-time adjustment, not a run-time
conversion). The exceptions are the argument of sizeof, the argument of
unary "&", and a string literal in an initializer used to initialize an
array object; in those contexts, array expressions remain as array
expressions.

Second, a parameter defined with an array type is adjusted to a pointer
type. This:
void func(int param[42]);
is *exactly* equivalent to:
void func(int *param);

All the weird interactions between arrays and pointers, including the
behavior of multidimensional arrays (which are simply arrays of arrays),
follow from those two rules.

One consequence of these rules is that we usually manipulate array
objects via pointers to their elements, because most operations that
would act on array objects as a whole don't exist.

Something else I've found useful is to treat the words "array" and
"pointer" as adjectives, not nouns. Informally we can say "this is an
array", but it can be ambiguous. Instead, we can have an array type, an
array object, an array expression, an array value, etc. (where "an array
FOO" is "a FOO of array type" for FOO!=type).

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Guillaume <message@bottle.org> writes:
>> Le 18/11/2021 à 22:58, David Brown a écrit :

>> Now there are kind of exceptions to that, but that are purely
>> "hand-implemented" and have nothing to do with the language itself:
>> for instance, the typical malloc() behavior. Behind the scenes,
>> pointers returned by malloc() are "fat pointers", and you can also
>> implement your own fat pointers if you so wish. But the language
>> doesn't care. It has no provision for that, except you can do pointer
>> arithmetics to your heart's content.
>
>I'm not sure what you mean about malloc() returning "fat pointers".
>malloc() returns a void* with no information about the size or type of
>what it points to. Some implementations might provide a way to query
>the size of the allocated space, but that's not standard.

Many malloc implementations reserve additional space, either before
or after the allocated space for bookkeeping and alignment purposes.

Perhaps that is the source of Guillaume's "fat pointer" reference.

scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>Guillaume <message@bottle.org> writes:
>>> Le 18/11/2021 à 22:58, David Brown a écrit :
>
>>> Now there are kind of exceptions to that, but that are purely
>>> "hand-implemented" and have nothing to do with the language itself:
>>> for instance, the typical malloc() behavior. Behind the scenes,
>>> pointers returned by malloc() are "fat pointers", and you can also
>>> implement your own fat pointers if you so wish. But the language
>>> doesn't care. It has no provision for that, except you can do pointer
>>> arithmetics to your heart's content.
>>
>>I'm not sure what you mean about malloc() returning "fat pointers".
>>malloc() returns a void* with no information about the size or type of
>>what it points to. Some implementations might provide a way to query
>>the size of the allocated space, but that's not standard.
>
> Many malloc implementations reserve additional space, either before
> or after the allocated space for bookkeeping and alignment purposes.
>
> Perhaps that is the source of Guillaume's "fat pointer" reference.

Perhaps -- but typically that information is not stored in the pointer
itself. If it were, all void* values would have to store that extra
information.

(I think it's easier to store bookkeeping data before the allocated
space. If you store it after the space, it's hard to know where it is.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

In article <Y2UlJ.79170$ya3.75666@fx38.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
....
>>I'm not sure what you mean about malloc() returning "fat pointers".
>>malloc() returns a void* with no information about the size or type of
>>what it points to. Some implementations might provide a way to query
>>the size of the allocated space, but that's not standard.
>
>Many malloc implementations reserve additional space, either before
>or after the allocated space for bookkeeping and alignment purposes.
>
>Perhaps that is the source of Guillaume's "fat pointer" reference.

That's the way I took it. That, although not in the standard, and thus
completely outside of Keith's field of vision, that on most implementations
you can "reverse engineer" how your particular implementation of malloc
(and friends) works, and figure out how to use the data contained around
the pointer value returned by malloc to figure out things like how big the
malloc'd region is.

Totally non-portable, of course, but necessary in certain situations.

--
It's possible that leasing office space to a Starbucks is a greater liability
in today's GOP than is hitting your mother on the head with a hammer.

On 19/11/2021 21:52, Keith Thompson wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> Guillaume <message@bottle.org> writes:
>>>> Le 18/11/2021 à 22:58, David Brown a écrit :
>>
>>>> Now there are kind of exceptions to that, but that are purely
>>>> "hand-implemented" and have nothing to do with the language itself:
>>>> for instance, the typical malloc() behavior. Behind the scenes,
>>>> pointers returned by malloc() are "fat pointers", and you can also
>>>> implement your own fat pointers if you so wish. But the language
>>>> doesn't care. It has no provision for that, except you can do pointer
>>>> arithmetics to your heart's content.
>>>
>>> I'm not sure what you mean about malloc() returning "fat pointers".
>>> malloc() returns a void* with no information about the size or type of
>>> what it points to. Some implementations might provide a way to query
>>> the size of the allocated space, but that's not standard.
>>
>> Many malloc implementations reserve additional space, either before
>> or after the allocated space for bookkeeping and alignment purposes.
>>
>> Perhaps that is the source of Guillaume's "fat pointer" reference.
>
> Perhaps -- but typically that information is not stored in the pointer
> itself. If it were, all void* values would have to store that extra
> information.
>
> (I think it's easier to store bookkeeping data before the allocated
> space. If you store it after the space, it's hard to know where it is.)
>

That's the most common way for a simple malloc/free system.

It has always struck me as a mistake that C did things that way - in my
opinion, "free" should have taken an additional parameter of the size
for the deallocation.

On 20/11/2021 12:36, David Brown wrote:
> On 19/11/2021 21:52, Keith Thompson wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> Guillaume <message@bottle.org> writes:
>>>>> Le 18/11/2021 à 22:58, David Brown a écrit :
>>>
>>>>> Now there are kind of exceptions to that, but that are purely
>>>>> "hand-implemented" and have nothing to do with the language itself:
>>>>> for instance, the typical malloc() behavior. Behind the scenes,
>>>>> pointers returned by malloc() are "fat pointers", and you can also
>>>>> implement your own fat pointers if you so wish. But the language
>>>>> doesn't care. It has no provision for that, except you can do pointer
>>>>> arithmetics to your heart's content.
>>>>
>>>> I'm not sure what you mean about malloc() returning "fat pointers".
>>>> malloc() returns a void* with no information about the size or type of
>>>> what it points to. Some implementations might provide a way to query
>>>> the size of the allocated space, but that's not standard.
>>>
>>> Many malloc implementations reserve additional space, either before
>>> or after the allocated space for bookkeeping and alignment purposes.
>>>
>>> Perhaps that is the source of Guillaume's "fat pointer" reference.
>>
>> Perhaps -- but typically that information is not stored in the pointer
>> itself. If it were, all void* values would have to store that extra
>> information.
>>
>> (I think it's easier to store bookkeeping data before the allocated
>> space. If you store it after the space, it's hard to know where it is.)
>>
>
> That's the most common way for a simple malloc/free system.
>
> It has always struck me as a mistake that C did things that way - in my
> opinion, "free" should have taken an additional parameter of the size
> for the deallocation.

Yeah, that's how I always implemented deallocations in the days when I
had to code everthing.

I was suprised when I first came across C's free which magically didn't
need that info!

Rather an indulgence for a lower level systems language.

When I go to some pains to allocate a block of exactly 4096 bytes, I
expect the next 4096-byte block to follow immediately, not be offset
from it by 4, 8 or 28 bytes or however it decides to do it.

Worse if my block is only 8 or 16 bytes:

for (int i=0; i<10; ++i) {
p=malloc(8);
printf("%d\n",(int)p);
}

The first three compilers I tried (I think all using msvcrt), used 32
bytes per allocation. 300% overhead!

David Brown <david.brown@hesbynett.no> writes:
> On 19/11/2021 21:52, Keith Thompson wrote:
[...]
>> Perhaps -- but typically that information is not stored in the pointer
>> itself. If it were, all void* values would have to store that extra
>> information.
>>
>> (I think it's easier to store bookkeeping data before the allocated
>> space. If you store it after the space, it's hard to know where it is.)
>
> That's the most common way for a simple malloc/free system.
>
> It has always struck me as a mistake that C did things that way - in my
> opinion, "free" should have taken an additional parameter of the size
> for the deallocation.

Meh. That would have introduced another rich source of programming
errors (passing the wrong size). Probably most implementations would
have kept track of the size anyway, so they could detect errors. As
long as they're keeping track, why make the user do so as well?

Perhaps a lower-level allocator might be more efficient if user code is
required to keep track, but I don't think it would be all that useful
for most applications.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 20/11/2021 23:52, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 19/11/2021 21:52, Keith Thompson wrote:
> [...]
>>> Perhaps -- but typically that information is not stored in the pointer
>>> itself. If it were, all void* values would have to store that extra
>>> information.
>>>
>>> (I think it's easier to store bookkeeping data before the allocated
>>> space. If you store it after the space, it's hard to know where it is.)
>>
>> That's the most common way for a simple malloc/free system.
>>
>> It has always struck me as a mistake that C did things that way - in my
>> opinion, "free" should have taken an additional parameter of the size
>> for the deallocation.
>
> Meh. That would have introduced another rich source of programming
> errors (passing the wrong size).

You could also pass the wrong size to malloc, or the wrong pointer to free.

> Probably most implementations would
> have kept track of the size anyway, so they could detect errors.

I doubt that, unless it's for debugging mode.

If an application needs to allocate 100 million 32-byte nodes, which
would occupy 3.2GB by themselves, how much extra would be needed for the
size, 'just for checking'?

On my machine that seems to be 16 bytes per node, so 50% more. 1.6GB
extra just so someone can write:

free(p);

instead of:

free(p, sizeof(treenode));

possibly in just one place in the program.

It doesn't make sense.