On 16/12/2021 22:15, Stefan Ram wrote:
> 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.
>
>

Quoted from the "Abstract" at the beginning of the C standards:

"""
A lthough this International Standard is intended to guide knowledgeable
C language programmers as well as implementors of C language translation
systems, the document itself is not designed to serve as a tutorial.
"""

When someone asks the meaning of a traffic sign, you do not point them
to a law library. When someone asks the meaning of an expression in C,
you do not point them at the standards.

Once the OP has a stronger grasp of the language and more experience
working with it, then the standards are a useful /reference/ of precise
detail. They are not designed for education.

This group has a reputation for being far too concerned about the
minutiae of the standards than giving useable help and practical advice
to people with questions about C. There is space for all kinds of
discussion here, but it is important to try to meet people's questions
at an appropriate level.

On 12/17/2021 11:08 AM, David Brown wrote:
> On 16/12/2021 22:15, Stefan Ram wrote:
>> 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.
>>
>>
>
> Quoted from the "Abstract" at the beginning of the C standards:
>
> """
> A lthough this International Standard is intended to guide knowledgeable
> C language programmers as well as implementors of C language translation
> systems, the document itself is not designed to serve as a tutorial.
> """
>
> When someone asks the meaning of a traffic sign, you do not point them
> to a law library. When someone asks the meaning of an expression in C,
> you do not point them at the standards.
>
> Once the OP has a stronger grasp of the language and more experience
> working with it, then the standards are a useful /reference/ of precise
> detail. They are not designed for education.
>
> This group has a reputation for being far too concerned about the
> minutiae of the standards than giving useable help and practical advice
> to people with questions about C. There is space for all kinds of
> discussion here, but it is important to try to meet people's questions
> at an appropriate level.

True, and it's not just about "level" (which might sound patronizing).
More properly I'd say it is about the English language and wording.
"Standardese" is notoriously unfriendly at any level.

On Thursday, December 16, 2021 at 6:50:41 PM UTC-5, Bart wrote:
> 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.

Meredith and I both made mistakes. He should have said `(*(a+3))`. Since
he didn't say that, I should have pointed out his mistake. However, your
comment surprises me.

Were you referring to his statement as he originally wrote it? If so, what
are the "certain cases" you're referring to? `a[3]` has the type char, while
`a+3` has the type char* - it's hard for me to see how they could ever be
equivalent.

Or did you misread his statement the same way I did? If so, under what
circumstances would `a[3]` not be equivalent to `(*(a+3))`? Section
6.5.2.1p2 says:
> ... E1[E2] is identical to (*((E1)+(E2))).

On 17/12/2021 16:24, Manfred wrote:
> On 12/17/2021 11:08 AM, David Brown wrote:
>>
>> This group has a reputation for being far too concerned about the
>> minutiae of the standards than giving useable help and practical advice
>> to people with questions about C.  There is space for all kinds of
>> discussion here, but it is important to try to meet people's questions
>> at an appropriate level.
>
> True, and it's not just about "level" (which might sound patronizing).
> More properly I'd say it is about the English language and wording.
> "Standardese" is notoriously unfriendly at any level.

Yes indeed.

It's also important to remember that some people might not be as fluent
in English as others. While many of the non-native English speakers
here have excellent English skills, some might not. We (and that
definitely includes me) don't always write in a way that is easy to read
for those that are not as proficient. (At least no one has to try to
understand my Scottish accent in spoken English :-) )

None of this is a criticism of people who can and do discus the
standards in all their glory and complexity - that's is just as much a
part of what we do in this group. And topic drift in threads is the way
Usenet works - no one "owns" threads and expects focus on their
question. (We are not paid technical support, and we chat about what we
want.) But many of us could sometimes benefit from keeping in mind the
kind of answer that would be of most help to someone who asks a question.

On 17/12/2021 15:34, james...@alumni.caltech.edu wrote:
> On Thursday, December 16, 2021 at 6:50:41 PM UTC-5, Bart wrote:
>> 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.
>
> Meredith and I both made mistakes.

Well, the OP is a newbie and that is a genuine misunderstanding.

> He should have said `(*(a+3))`. Since
> he didn't say that, I should have pointed out his mistake. However, your
> comment surprises me.
>
> Were you referring to his statement as he originally wrote it? If so, what
> are the "certain cases" you're referring to? `a[3]`

I'm refering partly to his first paragraph (I'd only glanced at the rest
of the post), and partly to my original reply to that, which I will
repeat here:

-------------------------------------------------------
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.

-------------------------------------------------------

So I say that sometimes, *(a+3) can have the same vaue as a+3.

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

> 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.

Yes --- thanks. That's what I meant, but didn't write.

>> 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.

Yes, I think I will never make that mistake again because that corrected
my intuition now. I was thinking of a pointer as just a variable
holding an integer, but there is a type associated to it which totally
changes arithmetic with it. That's my new intuition. Thanks for
helping me get there --- and for checking my work in your previous post.

[...]

> 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.)

I got the hang of it. Let's see. I'll write the program with my
predictions in comments --- and run it.

--8<---------------cut here---------------start------------->8---
#include <stdio.h>
int main(void) {
int a[] = {1, 2, 3};
printf("%lu\n", (unsigned long) a); // some address
printf("%lu\n", (unsigned long) &a); // same address

printf("%lu bytes\n", (unsigned long) sizeof a); // 12 bytes
printf("%lu bytes\n", (unsigned long) sizeof &a); // 8 bytes

// this will jump 12 bytes to the right
printf("%lu\n", (unsigned long) (&a + 1));
printf("Jumped %lu bytes to the right\n",
(unsigned long) (&a + 1) - (unsigned long) &a);

// this will hump 36 bytes to the right
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---

%make arrint
cc -Wall -x c -g -std=c99 -pedantic-errors arrint.c -o arrint

%./arrint.exe
4294954036
4294954036
12 bytes
8 bytes
4294954048
Jumped 12 bytes to the right
4294954072
Jumped 36 bytes to the right
%

That looks good! Thanks very much!

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

> 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" :-)

For the record, I enjoyed the simplicity of this (sub)thread. I was
trying to understand why my expectation was wrong. So, I was already in
some trouble; bringing in more details at that point would not have
helped more than not bringing them in.

It's also nice to see that the situation is even deeper than I would
have thought, though. For instance, right now my intuition is that the
size of a pointer on a 64-bit machine is always 8 bytes. Can anyone
show an easy example of when this isn't true?

[...]

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

> 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.

Indeed. Thanks. (I was aware of that. In fact, I thought that my OP
would produce a lot of --- that's undefined behavior and, so, C has
nothing to do with it. Lol. But, thankfully, you guys went straight
into helping me clear up my troubles.)

> 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'.

Wow, that's a cool application. Thanks for sharing.

I needed to redefine my definition of ``end''. I tend to think the end
of an array is its last byte, but agreed --- that's not quite its end
yet. It seems hard to define the exact end of something.

The end of my property should be on my property or should it be outside
of it? If *it* is outside, then because because *it* is relative to
*my* property, this *it* must be mine, so it belongs to my property. So
it's not outside of it. :-)

I would have done

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

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

> 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.)

Understood. Thanks!

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:
>>>
>>>> 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].

Understood.

[...]

>>>> #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.)

Thanks. Not long ago, I think I myself initiated some thread where I
learned about these PRI* constants for printf and where to find
documentation for them. But the uintptr_t is new to me. Thanks for the
info.

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

> On 16/12/2021 22:15, Stefan Ram wrote:

[...]

>> The best education is to get a copy of the C standard and
>> then look up the operators you are interested in.
>
> Quoted from the "Abstract" at the beginning of the C standards:
>
> """
> A lthough this International Standard is intended to guide knowledgeable
> C language programmers as well as implementors of C language translation
> systems, the document itself is not designed to serve as a tutorial.
> """
>
> When someone asks the meaning of a traffic sign, you do not point them
> to a law library. When someone asks the meaning of an expression in C,
> you do not point them at the standards.
>
> Once the OP has a stronger grasp of the language and more experience
> working with it, then the standards are a useful /reference/ of precise
> detail. They are not designed for education.
>
> This group has a reputation for being far too concerned about the
> minutiae of the standards than giving useable help and practical advice
> to people with questions about C. There is space for all kinds of
> discussion here, but it is important to try to meet people's questions
> at an appropriate level.

``A man after my own heart.''

Meredith Montgomery <mmontgomery@levado.to> writes:
>of an array is its last byte, but agreed --- that's not quite its end
>yet. It seems hard to define the exact end of something.

I have developed my personal terminology for integer ranges:

For example, take the range { 3, 4, 5, 6, 7 }.

The "begin of the range" is the first number of the range,
i.e., 3.

The "bottom of the range" is the number before the first
number of the range, i.e., 2.

The "end of the range" is the last number of the range,
i.e., 7.

The "top of the range" is the number after the last number
of the range, i.e., 8.

In the standard library of C++, they call "end" what I
call "top".

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].
>
>> 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).

Thanks for the citation and the technical analysis. Much appreciated.

[...]

>> 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], [...]

You must have skipped a letter while counting. With '\0' at the end, we
get char[13], but that did not complicated the reading in any way.

[...]

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.
>
>> 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.

I assumed you just skipped a letter, which could happen to anyone.

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Meredith Montgomery <mmontgomery@levado.to> writes:
>>of an array is its last byte, but agreed --- that's not quite its end
>>yet. It seems hard to define the exact end of something.
>
> I have developed my personal terminology for integer ranges:
>
> For example, take the range { 3, 4, 5, 6, 7 }.
>
> The "begin of the range" is the first number of the range,
> i.e., 3.
>
> The "bottom of the range" is the number before the first
> number of the range, i.e., 2.
>
> The "end of the range" is the last number of the range,
> i.e., 7.
>
> The "top of the range" is the number after the last number
> of the range, i.e., 8.
>
> In the standard library of C++, they call "end" what I
> call "top".

That's interesting. In technical context, it's nice to have a language
that reflects distinctions where there is.

Meredith Montgomery <mmontgomery@levado.to> writes:
>David Brown <david.brown@hesbynett.no> writes:
>

>>
>> 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" :-)
>
[snip]
>It's also nice to see that the situation is even deeper than I would
>have thought, though. For instance, right now my intuition is that the
>size of a pointer on a 64-bit machine is always 8 bytes. Can anyone
>show an easy example of when this isn't true?

That statement may be considered true for the current generation
of general purpose hardware, albeit dependent upon your definition
of 64-bit machine as supporting a 64-bit address on its bus/mesh/ring.

A system may support 64-bit arithmetic natively without supporing
more than a 32-bit address space, particularly in harvard-style
architectures.

There are systems under design right now that have 128-bit pointers,
yet only support a 64-bit address space (i.e the maximum address that
can be presented to a 'Load' or 'Store' instruction); these larger
pointers can contain 64-bits of metadata (e.g. the size of the region
covered by the pointer and access controls for reads vs. writes)
allowing the processor to efficiently prevent access outside the bounds of an object,
or to prevent stores to a read-only object.

https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-faq.html

On 12/18/2021 4:02 PM, Meredith Montgomery wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> 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.
>
> Indeed. Thanks. (I was aware of that. In fact, I thought that my OP
> would produce a lot of --- that's undefined behavior and, so, C has
> nothing to do with it. Lol. But, thankfully, you guys went straight
> into helping me clear up my troubles.)
>
>> 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'.
>
> Wow, that's a cool application. Thanks for sharing.
>
> I needed to redefine my definition of ``end''. I tend to think the end
> of an array is its last byte, but agreed --- that's not quite its end
> yet. It seems hard to define the exact end of something.
>
> The end of my property should be on my property or should it be outside
> of it? If *it* is outside, then because because *it* is relative to
> *my* property, this *it* must be mine, so it belongs to my property. So
> it's not outside of it. :-)
>
> I would have done
>
> char *end_of_buffer = (&buffer)[1] - 1;
>

It's more about habits in the context of C and how this "end" is used.

C uses the convention that indexes start at 0, which implies that a
collection of N elements has length N and is indexed from 0 to N-1.
Following the same reasoning, the following is customary in C:

#define N 42
int arr[N];
int* start = arr;
int* first = arr;
int* last = arr+N-1;
int* end = arr+N;

"end" defined this way is never dereferenced, but is typically used
(a.o.) as:

for (int* p = start; p != end; ++p)
{ *p = whatever;
}

Writing the same loop using "last" is also possible, but requires using
"<=" with pointers, which involves additional ordering requirements.

The standard follows the same habit, but is more accurate: it usually
refers to the boundary of a collection as "one past the end" of it.
However, it is this "one past the end" that is more often used rather
than the "last element" of the collection.
In fact, the "one past the end" pointer gets special attention from the
standard for the very purpose of making code like the above legal.

On 18/12/2021 15:39, Meredith Montgomery wrote:

>
> It's also nice to see that the situation is even deeper than I would
> have thought, though. For instance, right now my intuition is that the
> size of a pointer on a 64-bit machine is always 8 bytes. Can anyone
> show an easy example of when this isn't true?
>

There is the x32 ABI, which is an alternative ABI for 64-bit x86 systems
that uses 32-bit pointers but 64-bit integer registers and the
additional features and registers that x86-64 provides beyond x86-32.
The result was more efficient for some kinds of code, but it never
really took off. Some Linux distributions provide support for it (such
as libraries) alongside their main 64-bit stuff.

There are also a few systems, mostly historic and/or academic, that have
wider pointers containing security or protection information in addition
to addresses.

It is usually in smaller systems and nice areas (like DSPs) that you
have unusual sizes. For example, gcc for the the 8-bit AVR
microcontroller family has 16-bit int, 16-bit pointers for data and code
that are separate address spaces (i.e., a data pointer and a function
pointer could contain the same "value" if you were to cast them to a
uintptr_t, yet, point to completely different memory locations). It
also has 24-bit code pointers, and 24-bit generic pointers as well.
This is the best example I know of for strangely sized and incompatible
pointers, in devices that are popular and modern.

On 18/12/2021 14:39, Meredith Montgomery wrote:
> David Brown <david.brown@hesbynett.no> writes:

>> 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" :-)
>
> For the record, I enjoyed the simplicity of this (sub)thread. I was
> trying to understand why my expectation was wrong. So, I was already in
> some trouble; bringing in more details at that point would not have
> helped more than not bringing them in.
>
> It's also nice to see that the situation is even deeper than I would
> have thought, though. For instance, right now my intuition is that the
> size of a pointer on a 64-bit machine is always 8 bytes. Can anyone
> show an easy example of when this isn't true?

C running on a typical 64-bit desktop PC will have sizeof(int) as 4
bytes, and sizeof(void*) as 8 bytes.

Unless you tell it to use a 32-bit target (eg. using -m32 option), when
pointers will be 4 bytes.

There might be a few odd implementations where it's different (for
example I've implemented a language with 32-bit pointers even in 64-bit
mode), but I wouldn't worry about that.

Meredith Montgomery <mmontgomery@levado.to> writes:

> I needed to redefine my definition of ``end''. I tend to think the end
> of an array is its last byte, but agreed --- that's not quite its end
> yet. It seems hard to define the exact end of something.

C permits, for largely historical reasons, the construction of a pointer
"just past" the end of an object. As a result, you can process an array
(or some part of an array) with a conventional idiom:

for (char *ptr = start; ptr < end; ptr++) ...

which parallels the method using indexes:

for (int i = 0; i < n; i++) ...

You can get the index from the pointer (start - ptr) and the pointer
form the index (start + i) and everything works provided you don't
access the data at the "just past" address.

> The end of my property should be on my property or should it be outside
> of it? If *it* is outside, then because because *it* is relative to
> *my* property, this *it* must be mine, so it belongs to my property. So
> it's not outside of it. :-)

It's handy that the start and the end are not the same pointer unless
the range is zero. When you get into the habit of using the "just past"
pointer you will find all sorts of little things drop into place.

--
Ben.

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

> On 18/12/2021 15:39, Meredith Montgomery wrote:
>
>>
>> It's also nice to see that the situation is even deeper than I would
>> have thought, though. For instance, right now my intuition is that the
>> size of a pointer on a 64-bit machine is always 8 bytes. Can anyone
>> show an easy example of when this isn't true?
>>
>
> There is the x32 ABI, which is an alternative ABI for 64-bit x86 systems
> that uses 32-bit pointers but 64-bit integer registers and the
> additional features and registers that x86-64 provides beyond x86-32.
> The result was more efficient for some kinds of code, but it never
> really took off. Some Linux distributions provide support for it (such
> as libraries) alongside their main 64-bit stuff.
>
> There are also a few systems, mostly historic and/or academic, that have
> wider pointers containing security or protection information in addition
> to addresses.
>
> It is usually in smaller systems and nice areas (like DSPs) that you
> have unusual sizes. For example, gcc for the the 8-bit AVR
> microcontroller family has 16-bit int, 16-bit pointers for data and code
> that are separate address spaces (i.e., a data pointer and a function
> pointer could contain the same "value" if you were to cast them to a
> uintptr_t, yet, point to completely different memory locations). It
> also has 24-bit code pointers, and 24-bit generic pointers as well.
> This is the best example I know of for strangely sized and incompatible
> pointers, in devices that are popular and modern.

Nice to know. Thank you and everyone else that also contributed.