I'm investigating the syntax array[index] and I'm getting surprised at
some places. My intuition says that a[3] is the same as a + 3. I also
know that /&a/ is the same as /a/. I first expected the following
program to print ``lo, world\n'' three times, but it does not.

--8<---------------cut here---------------start------------->8---
#include <stdio.h>
int main() {
char a[] = "hello, world";
printf("a: %s\n", &a[3]);
printf("a: %s\n", a + 3);
printf("a: %s\n", &a + 3);
} --8<---------------cut here---------------end--------------->8---

%./hello.exe
a: lo, world
a: lo, world
a: ▒
%

I think part of my problem is a type-confusion I'm making. The type of
a + 3 must still be (char *) while the third one must be some other
type?

I get the my-expected result this way:

--8<---------------cut here---------------start------------->8---
#include <stdio.h>
int main() {
char a[] = "hello, world";
printf("a: %s\n", &a[3]);
printf("a: %s\n", a + 3);
printf("a: %s\n", (char*) &a + 3);
} --8<---------------cut here---------------end--------------->8---

So I think I must correct my intuition to remember that &var does not
produce a type ``char *''. What does it produce? Which reference could
I check to see an official statement of the fact?

My real request is --- can you educate me on this matter? I don't think
I'm looking at things in the proper way. For example,

printf("a: %s\n", (char*) (&a + 3));

produces the garbage I saw before.

Trying to see what's going on, I wrote

printf("a: %p\n", a);
printf("a: %p\n", a + 3);
printf("a: %p\n", &a + 3);

and I got

--8<---------------cut here---------------start------------->8---
%./hello.exe
a: 0xffffcc33
a: 0xffffcc36
a: 0xffffcc5a
--8<---------------cut here---------------end--------------->8---

which illustrates my misunderstanding. I expected the two last lines to
print ``a: 0xffffcc36'', but somehow ``&a + 3'' yields ``0xffffcc5a''
and not the 3 bytes further from 0xffffcc33 that I expected.

Thank you so much.

On 16/12/2021 14:13, Meredith Montgomery wrote:
> I'm investigating the syntax array[index] and I'm getting surprised at
> some places. My intuition says that a[3] is the same as a + 3.

It's the same as *(a+3).

However if a is an array of arrays, then the array element at *(a+3)
might decay to a pointer of that array, so it could end up as the same
value as a+3, if different type:

int a[5][4];

printf("%p\n", a[3]);
printf("%p\n", *(a+3));
printf("%p\n", a+3);

These all show the same address. But change 'a' to 'int a[5]', and the
first two lines show the value, the element a[3] (some random value if
not initialised), and the last shows the address of that element.

> I also
> know that /&a/ is the same as /a/.

The same /what/? Those have the same values but different types ((T*)[]
vs T* where T is a's element type).

Bart <bc@freeuk.com> writes:

> On 16/12/2021 14:13, Meredith Montgomery wrote:
>> I'm investigating the syntax array[index] and I'm getting surprised at
>> some places. My intuition says that a[3] is the same as a + 3.
>
> It's the same as *(a+3).
>
> However if a is an array of arrays, then the array element at *(a+3)
> might decay to a pointer of that array, so it could end up as the same
> value as a+3, if different type:
>
> int a[5][4];
>
> printf("%p\n", a[3]);
> printf("%p\n", *(a+3));
> printf("%p\n", a+3);
>
> These all show the same address. But change 'a' to 'int a[5]', and the
> first two lines show the value, the element a[3] (some random value if
> not initialised), and the last shows the address of that element.

Point taken. I have been considering just an array of characters, so
can we focus on this more restricted context?

>> I also
>> know that /&a/ is the same as /a/.
>
> The same /what/? Those have the same values but different types
> ((T*)[] vs T* where T is a's element type).

Oh, so that's at least part of what I didn't know. I'm trying to use
this new information to explain the numbers, but I haven't made it yet.

--8<---------------cut here---------------start------------->8---
#include <stdio.h>
int main() {
char a[] = "abc";
printf("a: %lu\n", a);
printf("a: %lu\n", a + 3);
printf("a: %lu\n", &a + 3);
} --8<---------------cut here---------------end--------------->8---

%./hello.exe
a: 4294954044
a: 4294954047
a: 4294954056
%

The array a is at 4294954044 and a + 3 is at 4294954047, as I expected.

Why is the third number at 4294954056? This is 9 bytes to the right of
a. Why 9 bytes? I thought it could be 3 times the array size, but the
array size is 4 bytes (there's an ending '\0' in there) and not 3. So
if that were the case, I'd answer 12 bytes to the right of /a/ and not 9
bytes.

Can you put me in the right track? Thank you.

On 16/12/2021 15:13, Meredith Montgomery wrote:
> I'm investigating the syntax array[index] and I'm getting surprised at
> some places. My intuition says that a[3] is the same as a + 3. I also
> know that /&a/ is the same as /a/. I first expected the following
> program to print ``lo, world\n'' three times, but it does not.

I can see why you are confused - you are close, but a bit mixed up.

"a[3]" is the same as "*(a + 3)". The dereferencing is crucial.

In the code below, "a" is an array of 13 char - and that is its type.
When you take its address, "&a", you have a pointer to an array of 13
char. This will have the same /value/ as &a[0], which is a pointer to
the first element of the array - a pointer to a char.

In many expressions (apart from "sizeof a" or "&a"), "a" will decay to a
pointer to its first element. That is, the "array of char" is turned
into a "pointer to char". And this pointer will have the same /value/
as &a[0], and therefore as &a. But it is not the same thing, even when
used in an expression - types are very important.

>
> --8<---------------cut here---------------start------------->8---
> #include <stdio.h>
> int main() {
> char a[] = "hello, world";
> printf("a: %s\n", &a[3]);

&a[3] is the address of element 3 (i.e., the fourth letter) of the array
"a".

> printf("a: %s\n", a + 3);

"a" here gets converted to a pointer to the first element, and then 3
elements are added - giving a pointer to a char at the address of element 3.

> printf("a: %s\n", &a + 3);

"a" here is the full array, so "&a" is a pointer to an array of 13 char.
Adding 3 gives a new pointer to an array of 13 char, at the address 39
bytes higher than address of "a". Basically, you are pretending that
there is an array of 4 elements, each of which is itself an array of 13
chars - with "a" being the first of those 4 elements. Now you are
asking to print the 4th element here, which is just whatever happens to
be in the memory at that address.

> }
> --8<---------------cut here---------------end--------------->8---
>
> %./hello.exe
> a: lo, world
> a: lo, world
> a: ▒
> %
>
> I think part of my problem is a type-confusion I'm making. The type of
> a + 3 must still be (char *) while the third one must be some other
> type?

Yes. Understanding the source of your confusion is the first step
towards resolving it.

>
> I get the my-expected result this way:
>
> --8<---------------cut here---------------start------------->8---
> #include <stdio.h>
> int main() {
> char a[] = "hello, world";
> printf("a: %s\n", &a[3]);
> printf("a: %s\n", a + 3);
> printf("a: %s\n", (char*) &a + 3);
> }
> --8<---------------cut here---------------end--------------->8---
>
> So I think I must correct my intuition to remember that &var does not
> produce a type ``char *''. What does it produce? Which reference could
> I check to see an official statement of the fact?

For a good reference, I like "en.cppreference.com". Here are some
relevant pages:

<https://en.cppreference.com/w/c/language/conversion>
<https://en.cppreference.com/w/c/language/operator_member_access>
<https://en.cppreference.com/w/c/language/array>

That site is an easier reference than reading the standards. But it is
still a reference - you may want a tutorial page rather than a reference.

>
> My real request is --- can you educate me on this matter? I don't think
> I'm looking at things in the proper way. For example,
>
> printf("a: %s\n", (char*) (&a + 3));
>
> produces the garbage I saw before.
>
> Trying to see what's going on, I wrote
>
> printf("a: %p\n", a);
> printf("a: %p\n", a + 3);
> printf("a: %p\n", &a + 3);
>
> and I got
>
> --8<---------------cut here---------------start------------->8---
> %./hello.exe
> a: 0xffffcc33
> a: 0xffffcc36
> a: 0xffffcc5a
> --8<---------------cut here---------------end--------------->8---
>
> which illustrates my misunderstanding. I expected the two last lines to
> print ``a: 0xffffcc36'', but somehow ``&a + 3'' yields ``0xffffcc5a''
> and not the 3 bytes further from 0xffffcc33 that I expected.
>
> Thank you so much.
>

I think you should be able to figure this out now, given what I wrote
earlier.

Meredith Montgomery <mmontgomery@levado.to> writes:

> Bart <bc@freeuk.com> writes:
>> On 16/12/2021 14:13, Meredith Montgomery wrote:

>>> I also
>>> know that /&a/ is the same as /a/.
>>
>> The same /what/? Those have the same values but different types
>> ((T*)[] vs T* where T is a's element type).

In this specific case, char (*)[4] and char *. (T*)[] is not a valid
type (for some base type T), and even with the syntax corrected (it's
T(*)[]), it's still wrong because the size is missing. C does have
array types with no size, but none are relevant to your case.

> Oh, so that's at least part of what I didn't know. I'm trying to use
> this new information to explain the numbers, but I haven't made it
> yet.

Take care with Bart's replies. He loves to make things sound more
complicated than then really are, and in this case the types he wrote
are wrong. Also, pointer to array types are rarely used in C, so while
it's worth knowing about them, must people learn a lot of C before
coming across them.

> #include <stdio.h>
> int main() {
> char a[] = "abc";
> printf("a: %lu\n", a);
> printf("a: %lu\n", a + 3);
> printf("a: %lu\n", &a + 3);
> }

With any luck, you compiler should have had lots to say about this
code. If it did not, turn up the warnings. I'll write it my way with
comments.

#include <stdio.h>
int main(void) { // Empty ()s here have a special, archaic, meaning.
char a[] = "abc";
// Declare a to be an array of 4 characters initialised with
// 'a', 'b', 'c' and '\0'.
printf("a: %p\n", (void *)a);
// C has a format for pointers (%p), but you must convert the
// pointer to the expected type of void *.
printf("a: %p\n", (void *)(a + 3));
printf("a: %p\n", (void *)(&a + 3));
}

> %./hello.exe
> a: 4294954044

This is the address of a -- the address of the first element. Pointers
in C are addresses with type information.

> a: 4294954047

This is the address of the null at the end of the array. An array name,
in most contexts, converts to a pointer to the first element, so a here
is of type char *. Pointer arithmetic is done by adding units of the
size of the pointed-to type and, since sizeof(char) is 1, that adds
three.

> a: 4294954056

An array as the operand of & is one of very few cases where the
conversion to a pointer to the first element does not occur. The result
is a pointer to the whole four-byte array. Adding 3 therefore adds 3
times the size of that object, i.e. 12.

--
Ben.

On 16/12/2021 17:42, Ben Bacarisse wrote:
> Meredith Montgomery <mmontgomery@levado.to> writes:
>
>> Bart <bc@freeuk.com> writes:
>>> On 16/12/2021 14:13, Meredith Montgomery wrote:
>
>>>> I also
>>>> know that /&a/ is the same as /a/.
>>>
>>> The same /what/? Those have the same values but different types
>>> ((T*)[] vs T* where T is a's element type).
>
> In this specific case, char (*)[4] and char *. (T*)[] is not a valid
> type (for some base type T), and even with the syntax corrected (it's
> T(*)[]),

OK.

> it's still wrong because the size is missing.

When the OP wrote about a[3] at the top of the post, there was no
declaration for 'a' and therefore no size. My remark applied to an array
of any type.

And using [] generally means an array of any size.

(You can write a function taking T(*)[], and call it with T(*)[3] or
T(*)[300].)

>> Oh, so that's at least part of what I didn't know. I'm trying to use
>> this new information to explain the numbers, but I haven't made it
>> yet.
>
> Take care with Bart's replies. He loves to make things sound more
> complicated than then really are, and in this case the types he wrote
> are wrong. Also, pointer to array types are rarely used in C, so while
> it's worth knowing about them,

Well, the OP mentioned &a, and that is its type.

David Brown <david.brown@hesbynett.no> writes:

> On 16/12/2021 15:13, Meredith Montgomery wrote:
>> I'm investigating the syntax array[index] and I'm getting surprised at
>> some places. My intuition says that a[3] is the same as a + 3. I also
>> know that /&a/ is the same as /a/. I first expected the following
>> program to print ``lo, world\n'' three times, but it does not.
>
> I can see why you are confused - you are close, but a bit mixed up.
>
> "a[3]" is the same as "*(a + 3)". The dereferencing is crucial.

Thank you!

> In the code below, "a" is an array of 13 char - and that is its type.
> When you take its address, "&a", you have a pointer to an array of 13
> char. This will have the same /value/ as &a[0], which is a pointer to
> the first element of the array - a pointer to a char.

Yes, so that corrects me at least once. I didn't think &a would be of a
different type. So the type of &a is array of 13 char. I get that.
The value of &a is the same /value/ as &a[0]. I also get that. I'm
good here.

> In many expressions (apart from "sizeof a" or "&a"), "a" will decay to a
> pointer to its first element. That is, the "array of char" is turned
> into a "pointer to char". And this pointer will have the same /value/
> as &a[0], and therefore as &a. But it is not the same thing, even when
> used in an expression - types are very important.

Alright, I got it now. The types change, but the values are the same.
So all care must taken precisely when pointer arithmetic is used because
the types are totally determinant there.

>> --8<---------------cut here---------------start------------->8---
>> #include <stdio.h>
>> int main() {
>> char a[] = "hello, world";
>> printf("a: %s\n", &a[3]);
>
> &a[3] is the address of element 3 (i.e., the fourth letter) of the array
> "a".
>
>> printf("a: %s\n", a + 3);
>
> "a" here gets converted to a pointer to the first element, and then 3
> elements are added - giving a pointer to a char at the address of element 3.

I'm good there too.

>> printf("a: %s\n", &a + 3);
>
> "a" here is the full array, so "&a" is a pointer to an array of 13 char.
> Adding 3 gives a new pointer to an array of 13 char, at the address 39
> bytes higher than address of "a". Basically, you are pretending that
> there is an array of 4 elements, each of which is itself an array of 13
> chars - with "a" being the first of those 4 elements. Now you are
> asking to print the 4th element here, which is just whatever happens to
> be in the memory at that address.

Let me do the arithmetic and see if I get the same thing. Since &a is a
pointer to an array of 13 char, then I would say that

&a + 1

should jump 13 bytes ``to the right'' because that is the size of the
array to which &a points to. That appears to be the case. The 39
bytes, therefore, is due to 13 * 3.

Confirming that:

--8<---------------cut here---------------start------------->8---
#include <stdio.h>
int main(void) {
char a[] = "hello, world";
printf("%lu\n", (unsigned long) a);
printf("%lu\n", (unsigned long) &a);
printf("%lu\n", (unsigned long) (&a + 1));
printf("Jumped %lu bytes to the right\n",
(unsigned long) (&a + 1) - (unsigned long) &a);
printf("%lu\n", (unsigned long) (&a + 3));
printf("Jumped %lu bytes to the right\n",
(unsigned long) (&a + 3) - (unsigned long) &a);
} --8<---------------cut here---------------end--------------->8---

%./arr
4294954035
4294954035
4294954048
Jumped 13 bytes to the right
4294954074
Jumped 39 bytes to the right
%

If that's indeed right, then things are falling into place now. Thank
you so much, David! As always, I'm very grateful!

By the way, I'm using (unsigned long) and %lu because I wanted the
numbers in base 10 for an easier arithmetic life.
>> %./hello.exe
>> a: lo, world
>> a: lo, world
>> a: ▒
>> %
>>
>> I think part of my problem is a type-confusion I'm making. The type of
>> a + 3 must still be (char *) while the third one must be some other
>> type?
>
> Yes. Understanding the source of your confusion is the first step
> towards resolving it.

If I'm not there yet, I should be close because things seem to be
working as I now expect.

[...]

> I think you should be able to figure this out now, given what I wrote
> earlier.

I think that I did. Very grateful!

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Meredith Montgomery <mmontgomery@levado.to> writes:
>
>> Bart <bc@freeuk.com> writes:
>>> On 16/12/2021 14:13, Meredith Montgomery wrote:
>
>>>> I also
>>>> know that /&a/ is the same as /a/.
>>>
>>> The same /what/? Those have the same values but different types
>>> ((T*)[] vs T* where T is a's element type).
>
> In this specific case, char (*)[4] and char *. (T*)[] is not a valid
> type (for some base type T), and even with the syntax corrected (it's
> T(*)[]), it's still wrong because the size is missing. C does have
> array types with no size, but none are relevant to your case.

Thanks for the correction. I'll repeat what you say in my words just to
get a chance that you might verify what I'm saying. When I have an
array such as

char a[] = "hello, world"

which occupies 13 bytes, then a pointer to it is a pointer of type

char (*a)[13]

and that's how we write its type --- although I could omit the letter a
there, perhaps I should, I also think it's okay to write it there. Bart
effectively wrote (char*)[], which is not the same or perhaps not a
valid type at all. That's my understanding now.

>> Oh, so that's at least part of what I didn't know. I'm trying to use
>> this new information to explain the numbers, but I haven't made it
>> yet.
>
> Take care with Bart's replies. He loves to make things sound more
> complicated than then really are, and in this case the types he wrote
> are wrong. Also, pointer to array types are rarely used in C, so while
> it's worth knowing about them, must people learn a lot of C before
> coming across them.

Thanks for the advice. I'm still going to study declarations. I do
think they're pretty difficult, but I believe they don't appear too
often. Brian Kernighan says the same in the book.

>> #include <stdio.h>
>> int main() {
>> char a[] = "abc";
>> printf("a: %lu\n", a);
>> printf("a: %lu\n", a + 3);
>> printf("a: %lu\n", &a + 3);
>> }
>
> With any luck, you compiler should have had lots to say about this
> code. If it did not, turn up the warnings. I'll write it my way with
> comments.

Yes, the warnings were there. In my new experiment I added casts, but
kept the %lu because I wanted to see things in base 10.

> #include <stdio.h>
> int main(void) { // Empty ()s here have a special, archaic, meaning.
> char a[] = "abc";
> // Declare a to be an array of 4 characters initialised with
> // 'a', 'b', 'c' and '\0'.
> printf("a: %p\n", (void *)a);
> // C has a format for pointers (%p), but you must convert the
> // pointer to the expected type of void *.
> printf("a: %p\n", (void *)(a + 3));
> printf("a: %p\n", (void *)(&a + 3));
> }
>
>> %./hello.exe
>> a: 4294954044
>
> This is the address of a -- the address of the first element. Pointers
> in C are addresses with type information.

That's good info! I must keep this in mind --- addresses with type
information. Thank you!

>> a: 4294954047
>
> This is the address of the null at the end of the array. An array name,
> in most contexts, converts to a pointer to the first element, so a here
> is of type char *. Pointer arithmetic is done by adding units of the
> size of the pointed-to type and, since sizeof(char) is 1, that adds
> three.
>
>> a: 4294954056
>
> An array as the operand of & is one of very few cases where the
> conversion to a pointer to the first element does not occur. The result
> is a pointer to the whole four-byte array. Adding 3 therefore adds 3
> times the size of that object, i.e. 12.

Thank you. That's right --- I was expecting a conversion to a pointer
to the first element. I'm much better prepared now. Thanks a lot!

On 16/12/2021 20:25, Meredith Montgomery wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 16/12/2021 15:13, Meredith Montgomery wrote:
>>> I'm investigating the syntax array[index] and I'm getting surprised at
>>> some places. My intuition says that a[3] is the same as a + 3. I also
>>> know that /&a/ is the same as /a/. I first expected the following
>>> program to print ``lo, world\n'' three times, but it does not.
>>
>> I can see why you are confused - you are close, but a bit mixed up.
>>
>> "a[3]" is the same as "*(a + 3)". The dereferencing is crucial.
>
> Thank you!
>
>> In the code below, "a" is an array of 13 char - and that is its type.
>> When you take its address, "&a", you have a pointer to an array of 13
>> char. This will have the same /value/ as &a[0], which is a pointer to
>> the first element of the array - a pointer to a char.
>
> Yes, so that corrects me at least once. I didn't think &a would be of a
> different type. So the type of &a is array of 13 char. I get that.

/No/. "a" is of type "array of 13 char". "&a" is of type "pointer to
array of 13 char". These are different.

> The value of &a is the same /value/ as &a[0]. I also get that. I'm
> good here.

Correct. As Ben said (and Ben is very good at explaining things
accurately), a pointer has a type and has an address as it's value. So
the values of pointers here are the same, but the pointers themselves
are different because they have different types.

>
>> In many expressions (apart from "sizeof a" or "&a"), "a" will decay to a
>> pointer to its first element. That is, the "array of char" is turned
>> into a "pointer to char". And this pointer will have the same /value/
>> as &a[0], and therefore as &a. But it is not the same thing, even when
>> used in an expression - types are very important.
>
> Alright, I got it now. The types change, but the values are the same.
> So all care must taken precisely when pointer arithmetic is used because
> the types are totally determinant there.

Yes. Once you get used to the way array identifiers are converted into
pointers, it all works naturally and easily.

>
>>> --8<---------------cut here---------------start------------->8---
>>> #include <stdio.h>
>>> int main() {
>>> char a[] = "hello, world";
>>> printf("a: %s\n", &a[3]);
>>
>> &a[3] is the address of element 3 (i.e., the fourth letter) of the array
>> "a".
>>
>>> printf("a: %s\n", a + 3);
>>
>> "a" here gets converted to a pointer to the first element, and then 3
>> elements are added - giving a pointer to a char at the address of element 3.
>
> I'm good there too.
>
>>> printf("a: %s\n", &a + 3);
>>
>> "a" here is the full array, so "&a" is a pointer to an array of 13 char.
>> Adding 3 gives a new pointer to an array of 13 char, at the address 39
>> bytes higher than address of "a". Basically, you are pretending that
>> there is an array of 4 elements, each of which is itself an array of 13
>> chars - with "a" being the first of those 4 elements. Now you are
>> asking to print the 4th element here, which is just whatever happens to
>> be in the memory at that address.
>
> Let me do the arithmetic and see if I get the same thing. Since &a is a
> pointer to an array of 13 char, then I would say that
>
> &a + 1
>
> should jump 13 bytes ``to the right'' because that is the size of the
> array to which &a points to. That appears to be the case. The 39
> bytes, therefore, is due to 13 * 3.
>

Yes.

> Confirming that:
>
> --8<---------------cut here---------------start------------->8---
> #include <stdio.h>
> int main(void) {
> char a[] = "hello, world";
> printf("%lu\n", (unsigned long) a);
> printf("%lu\n", (unsigned long) &a);
> printf("%lu\n", (unsigned long) (&a + 1));
> printf("Jumped %lu bytes to the right\n",
> (unsigned long) (&a + 1) - (unsigned long) &a);
> printf("%lu\n", (unsigned long) (&a + 3));
> printf("Jumped %lu bytes to the right\n",
> (unsigned long) (&a + 3) - (unsigned long) &a);
> }
> --8<---------------cut here---------------end--------------->8---
>
> %./arr
> 4294954035
> 4294954035
> 4294954048
> Jumped 13 bytes to the right
> 4294954074
> Jumped 39 bytes to the right
> %
>
> If that's indeed right, then things are falling into place now. Thank
> you so much, David! As always, I'm very grateful!
>
> By the way, I'm using (unsigned long) and %lu because I wanted the
> numbers in base 10 for an easier arithmetic life.
>
>>> %./hello.exe
>>> a: lo, world
>>> a: lo, world
>>> a: ▒
>>> %
>>>
>>> I think part of my problem is a type-confusion I'm making. The type of
>>> a + 3 must still be (char *) while the third one must be some other
>>> type?
>>
>> Yes. Understanding the source of your confusion is the first step
>> towards resolving it.
>
> If I'm not there yet, I should be close because things seem to be
> working as I now expect.
>
> [...]
>
>> I think you should be able to figure this out now, given what I wrote
>> earlier.
>
> I think that I did. Very grateful!
>

Once you feel you have got the hang of this, repeat the whole thing with
an array of "int" rather than an array of "char". That will help you
appreciate where the scalings come in. (Note that while an "int" is 4
bytes, or 4 chars, on your platform, it is not necessarily the case on
other C implementations, especially for very small devices.)

On 12/16/2021 4:23 PM, David Brown wrote:
> On 16/12/2021 15:13, Meredith Montgomery wrote:
[...]
>
>> printf("a: %s\n", &a + 3);
>
> "a" here is the full array, so "&a" is a pointer to an array of 13 char.
> Adding 3 gives a new pointer to an array of 13 char, at the address 39
> bytes higher than address of "a". Basically, you are pretending that
> there is an array of 4 elements, each of which is itself an array of 13
> chars - with "a" being the first of those 4 elements. Now you are
> asking to print the 4th element here, which is just whatever happens to
> be in the memory at that address.
>

It might be worth mentioning that accessing memory at that address (&a +
3) technically yields undefined behavior, because it is an attempt to
access a location outside the array (a).
This is to say that attempting to access a memory location that has not
been explicitly allocated or mapped by the program is invalid in C.
Common practical results of many implementations might range from
printing garbage (as you say, whatever happens to be there), run into a
memory access violation (aka segmentation fault), or more unexpected
behaviors.

Meredith Montgomery <mmontgomery@levado.to> writes:
[...]
> Thanks for the correction. I'll repeat what you say in my words just to
> get a chance that you might verify what I'm saying. When I have an
> array such as
>
> char a[] = "hello, world"
>
> which occupies 13 bytes, then a pointer to it is a pointer of type
>
> char (*a)[13]
>
> and that's how we write its type --- although I could omit the letter a
> there, perhaps I should, I also think it's okay to write it there. Bart
> effectively wrote (char*)[], which is not the same or perhaps not a
> valid type at all. That's my understanding now.
[...]

The name "a" is not something you can arbitrarily decide to include or
omit.

`char (*)[13]` is a type name (pointer to array of 13 chars).

`char (*a)[13];` not a type name. It's a declaration. It declares an
object named `a` of type `char (*)[13]`. (And it needs that trailing
semicolon.)

--
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 */

David Brown <david.brown@hesbynett.no> writes:
> On 16/12/2021 20:25, Meredith Montgomery wrote:
[...]
>> Yes, so that corrects me at least once. I didn't think &a would be of a
>> different type. So the type of &a is array of 13 char. I get that.
>
> /No/. "a" is of type "array of 13 char". "&a" is of type "pointer to
> array of 13 char". These are different.
>
>> The value of &a is the same /value/ as &a[0]. I also get that. I'm
>> good here.
>
> Correct. As Ben said (and Ben is very good at explaining things
> accurately), a pointer has a type and has an address as it's value. So
> the values of pointers here are the same, but the pointers themselves
> are different because they have different types.

I don't think I'd say that &a and &a[0] have the same *value*, though it
depends on just what you mean by "value".

They refer to the same location in memory, so that `(void*)&a` and
`(void*)&a[0]` do have the same value. But they're of different types,
and a "value" in C includes its type. This can get a bit vague at
times, and it's common to handwave away the difference, even in the
standard. It can be particularly vague when were talking about numeric
values; are 3, 3U, and 3.0 the same value?

Note that `&a == &a[0]` is a constraint violation, in case you were
thinking that "same value" can be defined in terms of equality.

For pointers of different types, I suggest avoiding the issue by saying
that they refer to the same location.

The standard's definition of "value" (N1570 3.19) is:

precise meaning of the contents of an object when interpreted as
having a specific type

That definition is incomplete, since it excludes a "value" that results
from evaluation an expression. `2+2` has a value (spoiler: it's 4), but
that value is not the contents of any object.

[...]

--
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 */

Bart <bc@freeuk.com> writes:

> On 16/12/2021 17:42, Ben Bacarisse wrote:
>> Meredith Montgomery <mmontgomery@levado.to> writes:
>>
>>> Bart <bc@freeuk.com> writes:
>>>> On 16/12/2021 14:13, Meredith Montgomery wrote:
>>
>>>>> I also
>>>>> know that /&a/ is the same as /a/.
>>>>
>>>> The same /what/? Those have the same values but different types
>>>> ((T*)[] vs T* where T is a's element type).
>> In this specific case, char (*)[4] and char *. (T*)[] is not a valid
>> type (for some base type T), and even with the syntax corrected (it's
>> T(*)[]),
>
> OK.
>
>> it's still wrong because the size is missing.
>
> When the OP wrote about a[3] at the top of the post, there was no
> declaration for 'a' and therefore no size. My remark applied to an
> array of any type.

That was an array access, not a declaration. There was a declaration of
'a' in the post you replied to, but the type of &a in that context would
have been char (*)[13] as the initialiser was "hello, world".

> And using [] generally means an array of any size.

It actually means the array type is incomplete. That means the array
has an unknown size. I think "an array of any size" is too vague and
sounds more "useful" than incomplete array types really are.

> (You can write a function taking T(*)[], and call it with T(*)[3] or
> T(*)[300].)

Yes, a pointer to an incomplete array type is compatible with a pointer
to an array of a known size.

>>> Oh, so that's at least part of what I didn't know. I'm trying to use
>>> this new information to explain the numbers, but I haven't made it
>>> yet.
>> Take care with Bart's replies. He loves to make things sound more
>> complicated than then really are, and in this case the types he wrote
>> are wrong. Also, pointer to array types are rarely used in C, so while
>> it's worth knowing about them,
>
> Well, the OP mentioned &a, and that is its type.

It's type was (in the post you were replying to) char (*)[13]. Giving
the wrong syntax for a pointer to an incomplete array type using "T" as
the element type was, to my, mind over-complicating the reply.

--
Ben.

Meredith Montgomery <mmontgomery@levado.to> writes:
> My intuition says that a[3] is the same as a + 3.

Well, you need to know where to look it up. Intuition cannot
tell you this. You need to grab a copy of the C standard and
then lookup the section on those operators!

Alternatively, you can also read in a /draft/ of the C standard.
As far as I know, these drafts are published for discussion and
are available without pay.

>So I think I must correct my intuition to remember that &var does not
>produce a type ``char *''. What does it produce? Which reference could
>I check to see an official statement of the fact?

The same: a copy of the C standard.

>My real request is --- can you educate me on this matter?

The best education is to get a copy of the C standard and
then look up the operators you are interested in.

Meredith Montgomery <mmontgomery@levado.to> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Meredith Montgomery <mmontgomery@levado.to> writes:
>>
>>> Bart <bc@freeuk.com> writes:
>>>> On 16/12/2021 14:13, Meredith Montgomery wrote:
>>
>>>>> I also
>>>>> know that /&a/ is the same as /a/.
>>>>
>>>> The same /what/? Those have the same values but different types
>>>> ((T*)[] vs T* where T is a's element type).
>>
>> In this specific case, char (*)[4] and char *. (T*)[] is not a valid
>> type (for some base type T), and even with the syntax corrected (it's
>> T(*)[]), it's still wrong because the size is missing. C does have
>> array types with no size, but none are relevant to your case.
>
> Thanks for the correction. I'll repeat what you say in my words just to
> get a chance that you might verify what I'm saying. When I have an
> array such as
>
> char a[] = "hello, world"
>
> which occupies 13 bytes, then a pointer to it is a pointer of type
>
> char (*a)[13]
>
> and that's how we write its type --- although I could omit the letter a
> there, perhaps I should, I also think it's okay to write it there.

Not quite. When you write a type (for example, to use in a cast
operator) you must omit the name. If you include a name, then what you
are writing a declaration, not a type.

So, the object `a` has type char [13]. When used in a most contexts,
`a` is converted to an expression of type char *, but when you apply the
& operator, this conversion is not done and the pointer you get is of
type char (*)[13].

> Bart
> effectively wrote (char*)[], which is not the same or perhaps not a
> valid type at all. That's my understanding now.

Yes, that was just (I assume) a typo. Bart knows how to write pointer-
to-array types because his software uses them more than most C code
does. But the empty [] are wrong here. Your [13] is correct.

<cut>
>>> #include <stdio.h>
>>> int main() {
>>> char a[] = "abc";
>>> printf("a: %lu\n", a);
>>> printf("a: %lu\n", a + 3);
>>> printf("a: %lu\n", &a + 3);
>>> }
>>
>> With any luck, you compiler should have had lots to say about this
>> code. If it did not, turn up the warnings. I'll write it my way with
>> comments.
>
> Yes, the warnings were there. In my new experiment I added casts, but
> kept the %lu because I wanted to see things in base 10.

OK, so you converted the pointers to unsigned long. That will often
work, but "modern" C (since 1999), has an integer type that, if the
conversion is possible at all, is guaranteed to be the right width:
uintptr_t. It, along with a whole lot of other useful types, is
declared in <stdint.h>.

You might ask, how does one print such a type? Well there is another
header, <inttypes.h>, that defines macros with the right width:

printf("a is at %"PRIuPTR"\n", (uintptr_t)a);

A bit of a mouthful, but the result will work on any system where
pointers can be converted to some unsigned integer type. (There is also
a signed integer type intptr_t and a corresponding macro, PRIiPTR, for
printing it.)

--
Ben.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Meredith Montgomery <mmontgomery@levado.to> writes:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> Meredith Montgomery <mmontgomery@levado.to> writes:
[...]
>>>> #include <stdio.h>
>>>> int main() {
>>>> char a[] = "abc";
>>>> printf("a: %lu\n", a);
>>>> printf("a: %lu\n", a + 3);
>>>> printf("a: %lu\n", &a + 3);
>>>> }
>>>
>>> With any luck, you compiler should have had lots to say about this
>>> code. If it did not, turn up the warnings. I'll write it my way with
>>> comments.
>>
>> Yes, the warnings were there. In my new experiment I added casts, but
>> kept the %lu because I wanted to see things in base 10.
>
> OK, so you converted the pointers to unsigned long. That will often
> work, but "modern" C (since 1999), has an integer type that, if the
> conversion is possible at all, is guaranteed to be the right width:
> uintptr_t. It, along with a whole lot of other useful types, is
> declared in <stdint.h>.
>
> You might ask, how does one print such a type? Well there is another
> header, <inttypes.h>, that defines macros with the right width:
>
> printf("a is at %"PRIuPTR"\n", (uintptr_t)a);
>
> A bit of a mouthful, but the result will work on any system where
> pointers can be converted to some unsigned integer type. (There is also
> a signed integer type intptr_t and a corresponding macro, PRIiPTR, for
> printing it.)

Yes, but the usual way to print pointer values is to cast to void* and
use "%p".

The "%p" format produces a string that represents a pointer value in
some implementation-defined manner (hexadecimal is common). (Bart
mentioned this upthread.)

You can convert to uintptr_t and use %"PRIuPTR" if (a) you specifically
want decimal output for some reason and (b) you don't mind a slight loss
of portability (it can fail for pre-C99 implementations and for rare
implementations that don't have an integer type big enough to hold a
pointer value).

--
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 */

Manfred <noname@add.invalid> writes:

> On 12/16/2021 4:23 PM, David Brown wrote:
>> On 16/12/2021 15:13, Meredith Montgomery wrote:
> [...]
>>
>>> printf("a: %s\n", &a + 3);
>> "a" here is the full array, so "&a" is a pointer to an array of 13 char.
>> Adding 3 gives a new pointer to an array of 13 char, at the address 39
>> bytes higher than address of "a". Basically, you are pretending that
>> there is an array of 4 elements, each of which is itself an array of 13
>> chars - with "a" being the first of those 4 elements. Now you are
>> asking to print the 4th element here, which is just whatever happens to
>> be in the memory at that address.
>>
>
> It might be worth mentioning that accessing memory at that address (&a
> + 3) technically yields undefined behavior, because it is an attempt
> to access a location outside the array (a).

That's a good point to make. It reminds me of a construct that I rather
like:

char buffer[some-complex-size];
char *end_of_buffer = (&buffer)[1];

(&buffer)[1] means *(&buffer + 1). The constructed pointer &buffer + 1
is valid, and the * does not attempt to dereference it as *(&buffer + 1)
is an array-valued expression. It is, instead, converted to a pointer
to the first element of this non-existent array object -- a pointer one
past the end of 'buffer'.

--
Ben.

On 12/16/21 9:13 AM, Meredith Montgomery wrote:
> I'm investigating the syntax array[index] and I'm getting surprised at
> some places. My intuition says that a[3] is the same as a + 3. I also

That is correct. Interestingly, since a + 3 == 3 + a, it is also the
same as 3[a].

> know that /&a/ is the same as /a/. I first expected the following

That is incorrect. The relevant rule is

"Except when it is the operand of the sizeof operator, or the unary &
operator, or is a string literal used to initialize an array, an
expression that has type "array of type" is converted to an expression
with type "pointer to type" that points to the initial element of the
array object and is not an lvalue." (6.3.2.1p3).

Both the main rule, and two of the exceptions, comes into play in your
code below.

> program to print ``lo, world\n'' three times, but it does not.
>
> --8<---------------cut here---------------start------------->8---
> #include <stdio.h>
> int main() {
> char a[] = "hello, world";

"hello, world" is an expression of type char[12], and according to
6.3.2.1p3, would normally convert into a pointer to the 'h' at the start
of that array. In this context, that would be a constraint violation - a
pointer cannot be used to initialize an array. However, as explained in
6.3.2.1p3, that conversion does not occur when the string literal is
being used as an initializer for an array.

> printf("a: %s\n", &a[3]);

a[3] parses as a post-fix expression, and therefore as a
unary-expression, and the right operand of unary & is required to be a
unary expression.
Therefore, &a[3] gets parsed as &(a[3]), so 'a' does get converted into
a char* pointing at it's first element, so a[3] is equivalent to *(a+3).
The '&' doesn't apply to 'a' itself (which would prevent that conversion
from occurring), but to a[3], which is not an expression of array type,
so 6.3.2.1p3 doesn't come into play. Thus, we have the equivalent of
&*(a+3). The & and * cancel each other out, so it's simply a+3.

> printf("a: %s\n", a + 3);

'a' also converts into a pointer to it's first element here.

> printf("a: %s\n", &a + 3);

However, in this case a + 3 would be an additive expression. Unary &
cannot take an additive expression as it's right operand. Therefore,
this parses as (&a)+3. &a is one of the exceptions to the rule given in
6.3.2.1p3. Therefore, 'a' does NOT get converted into a value of pointer
type, which is good, because that value is explicitly not an lvalue, and
you can't take the address of something that isn't an lvalue.

'a' itself is an lvalue, and &a therefore results in a pointer of type
char(*)[12], a pointer to an entire array of 12 chars, not just one
char. And that's the fundamental problem.

The result of adding an integer to a pointer is defined in terms of
positions in an array of the pointed-at type. The pointed-at type in
this case is char[12]. There's only one such object in that location,
which is a itself. A single object of the pointed-at type is treated,
for the purposes of this rule, as if it were the first and only object
in a single-element array of the pointed-at type, or in other words, as
if it were char[1][12]. The problem is that you are asking it to move
the pointer 3 elements ahead in that array, and that array has only one
element. Such an expression has undefined behavior.

As a practical matter, what would happen on many systems is that they
would treats 'a' as if it were the first element in array[n][12], where
n is >= 4. Thus, (&a)+3 would result in a pointer to the 4th element of
that array. However, since there is not actually any such array, it
merely refers to whatever is actually located at the place where that
fourth element would have been, if it had existed. There's no guarantee
what's in that location, but it apparently is not another copy of the
"hello, world!" array.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Meredith Montgomery <mmontgomery@levado.to> writes:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>> Meredith Montgomery <mmontgomery@levado.to> writes:
> [...]
>>>>> #include <stdio.h>
>>>>> int main() {
>>>>> char a[] = "abc";
>>>>> printf("a: %lu\n", a);
>>>>> printf("a: %lu\n", a + 3);
>>>>> printf("a: %lu\n", &a + 3);
>>>>> }
>>>>
>>>> With any luck, you compiler should have had lots to say about this
>>>> code. If it did not, turn up the warnings. I'll write it my way with
>>>> comments.
>>>
>>> Yes, the warnings were there. In my new experiment I added casts, but
>>> kept the %lu because I wanted to see things in base 10.
>>
>> OK, so you converted the pointers to unsigned long. That will often
>> work, but "modern" C (since 1999), has an integer type that, if the
>> conversion is possible at all, is guaranteed to be the right width:
>> uintptr_t. It, along with a whole lot of other useful types, is
>> declared in <stdint.h>.
>>
>> You might ask, how does one print such a type? Well there is another
>> header, <inttypes.h>, that defines macros with the right width:
>>
>> printf("a is at %"PRIuPTR"\n", (uintptr_t)a);
>>
>> A bit of a mouthful, but the result will work on any system where
>> pointers can be converted to some unsigned integer type. (There is also
>> a signed integer type intptr_t and a corresponding macro, PRIiPTR, for
>> printing it.)
>
> Yes, but the usual way to print pointer values is to cast to void* and
> use "%p".

Yes, I wrote that out for the OP in my very first reply.

> You can convert to uintptr_t and use %"PRIuPTR" if (a) you specifically
> want decimal output for some reason

Later, the OP said they /did/ want to see decimal (presumably to make
the arithmetic even clearer) so I explained how to do that.

--
Ben.

On 16/12/2021 23:38, James Kuyper wrote:
> On 12/16/21 9:13 AM, Meredith Montgomery wrote:
>> I'm investigating the syntax array[index] and I'm getting surprised at
>> some places. My intuition says that a[3] is the same as a + 3. I also
>
> That is correct.

Really? It's only equivalent in certain cases.

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 12/16/21 9:13 AM, Meredith Montgomery wrote:
>> I'm investigating the syntax array[index] and I'm getting surprised at
>> some places. My intuition says that a[3] is the same as a + 3. I also
>
> That is correct. Interestingly, since a + 3 == 3 + a, it is also the
> same as 3[a].

I think you have not looked at what the OP wrote carefully enough.

a[3] == *(a + 3) == *(3 + a) == 3[a]

but not without the *(...) part!

--
Ben.

On 12/16/21 3:34 PM, Manfred wrote:
[re: char a[] = "hello, world!";
,,,
> It might be worth mentioning that accessing memory at that address (&a +
> 3) technically yields undefined behavior, because it is an attempt to
> access a location outside the array (a).

There's two problems with that statement. First of all, the expression
&a+3 has undefined behavior all by itself (6.5.6p9), even if the code
made no attempt to access the memory pointed at by the result of that
expression.
Secondly, such code simply has undefined behavior. There's no need to
qualify it with "technically". Undefined behavior simply means that the
standard doesn't impose any requirements on the resulting behavior - and
it doesn't impose any requirements on this code.
Keep in mind that undefined behavior allows, among infinitely many other
things, having the code behave in precisely the manner you incorrectly
thought it was required to behave. That case comes up pretty often,
which isn't a coincidence. The false idea that there is some particular
way that such code is required to behave doesn't just come out of
nowhere - it develops in part because there are real implementations
where it happens to have that behavior.

On 12/16/21 6:56 PM, Ben Bacarisse wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>
>> On 12/16/21 9:13 AM, Meredith Montgomery wrote:
>>> I'm investigating the syntax array[index] and I'm getting surprised at
>>> some places. My intuition says that a[3] is the same as a + 3. I also
>>
>> That is correct. Interestingly, since a + 3 == 3 + a, it is also the
>> same as 3[a].
>
> I think you have not looked at what the OP wrote carefully enough.

I did look closely enough.

> a[3] == *(a + 3) == *(3 + a) == 3[a]
>
> but not without the *(...) part!

I just forgot to put in the '*'. I also miscounted the length of the
array, which I consider to be even more embarrassing.

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 12/16/21 6:56 PM, Ben Bacarisse wrote:
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>
>>> On 12/16/21 9:13 AM, Meredith Montgomery wrote:
>>>> I'm investigating the syntax array[index] and I'm getting surprised at
>>>> some places. My intuition says that a[3] is the same as a + 3. I also
>>>
>>> That is correct. Interestingly, since a + 3 == 3 + a, it is also the
>>> same as 3[a].
>>
>> I think you have not looked at what the OP wrote carefully enough.
>
> I did look closely enough.

The OP wrote "a[3] is the same as a + 3" and you said "That is correct".

--
Ben.

On 16/12/2021 21:54, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 16/12/2021 20:25, Meredith Montgomery wrote:
> [...]
>>> Yes, so that corrects me at least once. I didn't think &a would be of a
>>> different type. So the type of &a is array of 13 char. I get that.
>>
>> /No/. "a" is of type "array of 13 char". "&a" is of type "pointer to
>> array of 13 char". These are different.
>>
>>> The value of &a is the same /value/ as &a[0]. I also get that. I'm
>>> good here.
>>
>> Correct. As Ben said (and Ben is very good at explaining things
>> accurately), a pointer has a type and has an address as it's value. So
>> the values of pointers here are the same, but the pointers themselves
>> are different because they have different types.
>
> I don't think I'd say that &a and &a[0] have the same *value*, though it
> depends on just what you mean by "value".

Yes, indeed it does. As always in threads like these, there is a
balance to be found between trying to have approximate explanations and
terms that are easier for the relative beginner OP, and trying to be as
accurate as possible with precise terms to help the OP get the details
right from the start (and of course there are always other people
reading the thread, who might benefit from more insight).

Objects in C always have a type, and they contain some sort of data -
which can reasonably be called its "value". For pointers, that will be
the address they contain - the value the OP is getting when he casts
these to an unsigned long and prints them out.

I know the real picture can be more complicated - different pointer
types can have different sizes, pointers can contain more than just an
address or memory location, two pointers of different types might
contain the same raw value but refer to different address spaces, they
might contain different raw values but refer to the same location and
may or may not compare equal, there can be trap representations, etc.
(That list is not complete.) So what I am writing is "lies to
children", rather than trying to be complete and precise (partly because
others here, such as yourself, are significantly better at that kind of
answer). If you are not familiar with the specific phrase "lies to
children", ask Santa for "The Science of the Discworld" :-)

>
> They refer to the same location in memory, so that `(void*)&a` and
> `(void*)&a[0]` do have the same value. But they're of different types,
> and a "value" in C includes its type. This can get a bit vague at
> times, and it's common to handwave away the difference, even in the
> standard. It can be particularly vague when were talking about numeric
> values; are 3, 3U, and 3.0 the same value?
>
> Note that `&a == &a[0]` is a constraint violation, in case you were
> thinking that "same value" can be defined in terms of equality.
>
> For pointers of different types, I suggest avoiding the issue by saying
> that they refer to the same location.

That might have been a better way to express it.

>
> The standard's definition of "value" (N1570 3.19) is:
>
> precise meaning of the contents of an object when interpreted as
> having a specific type
>
> That definition is incomplete, since it excludes a "value" that results
> from evaluation an expression. `2+2` has a value (spoiler: it's 4), but
> that value is not the contents of any object.
>

Lots of the standard's definitions can be a bit vague or incomplete, or
refer to other terms that are not defined - ultimately it is necessary
to rely on common sense or common programming concepts at some point.