Dereference an array pointer... UB?

[=?iso-8859-1?q?Tom=E1s_=D3_h=C9ilidhe?=]

Re: Dereference an array pointer... UB?

Keith Thompson:

An expression of array type is converted to a pointer. There has to
be something to convert in the first place.

Yes but an array type isn't a value -- which is the very reason why
arrays decay to a pointer to their first element, so that we can actually
get a value out of them.

--
Tomás Ó hÉilidhe

[Thad Smith]

Re: Dereference an array pointer... UB?

Tomás Ó hÉilidhe wrote:

Old Wolf:
>

>&X + 1 is a pointer to one-past-the-end.
>Dereferencin g such a pointer this causes UB.
>Doesn't matter what data type the pointer is.

>
>
That's a very superficial way of looking at it.
>
The REASON why it's UB to dereference a pointer to one-past-the-last is
because it could result in an out-of-bounds memory access.

I would say that the reason that the behavior is undefined is that the
committee didn't realize (or appreciate) the potential utility of defining
the meaning of the unary * operator on pointer values derived from pointers
to objects, but not themselves a pointer to an object.

--
Thad

[Kaz Kylheku]

Re: Dereference an array pointer... UB?

On Feb 12, 9:56 am, "Tomás Ó hÉilidhe" <t...@lavabit.c omwrote:

Keith Thompson:
>

An expression of array type is converted to a pointer.  There has to
be something to convert in the first place.

>
    Yes but an array type isn't a value -- which is the very reason why
arrays decay to a pointer to their first element, so that we can actually
get a value out of them.

And what value will you get from a nonexistent, imaginary array, after
decaying it to a pointer to a nonexistent first element?

[Ben Bacarisse]

Re: Dereference an array pointer... UB?

Kaz Kylheku <kkylheku@gmail .comwrites:

On Feb 12, 9:56 am, "Tomás Ó hÉilidhe" <t...@lavabit.c omwrote:

>Keith Thompson:
>>

An expression of array type is converted to a pointer.  There has to
be something to convert in the first place.

>>
>    Yes but an array type isn't a value -- which is the very reason why
>arrays decay to a pointer to their first element, so that we can actually
>get a value out of them.

>
And what value will you get from a nonexistent, imaginary array, after
decaying it to a pointer to a nonexistent first element?

You would get exactly the pointer the OP wanted -- to the int
immediately following the 1D array. I say "would" because I think the
example is UB, though only because the utility of applying * to an
array pointer (pointing "one past" a whole array) was missed when
drawing up the rule about applying * to these "one past" pointers.

--
Ben.

[Ben Bacarisse]

Re: Dereference an array pointer... UB?

Kaz Kylheku <kkylheku@gmail .comwrites:

On Feb 11, 10:21 am, "Tomás Ó hÉilidhe" <t...@lavabit.c omwrote:

>    Do you think we can reach any kind of consensus on whether the
>following code's behaviour is undefined by the Standard?
>>
>    int my_array[5];
>>
>    int const *const pend = *(&my_array + 1);

>
You may have a pointer one element past the last element of an array
object. However, my_array as whole is not an element of an array. So
&myarray + 1 is invalid.

That is not a problem. There is explicit permission to this.
Anything that is not an array element is to be treated as it it were
an array of length one.

What you are doing is similar to computing p below:
>
int i, j[1];
int *p = &i + 1; // not right, i is not an array object

Expressly permitted. You can apply the * to this pointer, but you may
calculate the inter value and store it.

int *q = &j + 1; // okay, since j is an array object

<snip>

--
Ben.

[Keith Thompson]

Re: Dereference an array pointer... UB?

Kaz Kylheku <kkylheku@gmail .comwrites:

On Feb 11, 10:21 am, "Tomás Ó hÉilidhe" <t...@lavabit.c omwrote:

>    Do you think we can reach any kind of consensus on whether the
>following code's behaviour is undefined by the Standard?
>>
>    int my_array[5];
>>
>    int const *const pend = *(&my_array + 1);

>
You may have a pointer one element past the last element of an array
object. However, my_array as whole is not an element of an array. So
&myarray + 1 is invalid.

No, &myarray + 1 is valid. C99 6.5.6p7 (Additive operators):

For the purposes of these operators, a pointer to an object that
is not an element of an array behaves the same as a pointer to the
first element of an array of length one with the type of the
object as its element type.

&my_array + 1 is a valid pointer value of type int(*)[5], pointing
just past the end of my_array.

Since this pointer value doesn't point to an object, attempting to
dereference it invokes UB, so *(&my_array + 1) is invalid.

What you are doing is similar to computing p below:
>
int i, j[1];
int *p = &i + 1; // not right, i is not an array object
int *q = &j + 1; // okay, since j is an array object

Again, &i + 1 is valid.

[snip]

--
Keith Thompson (The_Other_Keit h) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Kaz Kylheku]

Re: Dereference an array pointer... UB?

On Feb 13, 8:57 am, Ben Bacarisse <ben.use...@bsb .me.ukwrote:

Kaz Kylheku <kkylh...@gmail .comwrites:

On Feb 12, 9:56 am, "Tomás Ó hÉilidhe" <t...@lavabit.c omwrote:

Keith Thompson:

>

An expression of array type is converted to a pointer.  There has to
be something to convert in the first place.

>

    Yes but an array type isn't a value -- which is the very reasonwhy
arrays decay to a pointer to their first element, so that we can actually
get a value out of them.

>

And what value will you get from a nonexistent, imaginary array, after
decaying it to a pointer to a nonexistent first element?

>
You would get exactly the pointer the OP wanted -- to the int
immediately following the 1D array.

Of course, you would only get that if the implementation didn't throw
a diagnostic in your face and stop the program first. :)

> I say "would" because I think the
example is UB, though only because the utility of applying * to an
array pointer (pointing "one past" a whole array) was missed when
drawing up the rule about applying * to these "one past" pointers.

Exactly. Correctness is not just about getting the right value, but
about how you got it. What is 64/16? Ah, numerator 6 cancels the
denominator 6 so we get 4/1 = 4. :)

[Richard Heathfield]

Re: Dereference an array pointer... UB?

Peter Nilsson said:

<snip>

As quickly as you can, please tell me which of the
following functions has UB.

Both of them. (Both do illegal pointer comparisons.)

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Peter Nilsson]

Re: Dereference an array pointer... UB?

Richard Heathfield <r...@see.sig.i nvalidwrote:

Peter Nilsson said:
>
<snip>
>

As quickly as you can, please tell me which of the
following functions has UB.

>
Both of them. (Both do illegal pointer comparisons.)

Are you saying that because that's your "quickly as
you can" response, or because you genuinely think this
to be true?

If the latter, c&v for version 1 would be appreciated.

--
Peter

[Richard Heathfield]

Re: Dereference an array pointer... UB?

Peter Nilsson said:

Richard Heathfield <r...@see.sig.i nvalidwrote:

>Peter Nilsson said:
>>
><snip>
>>

As quickly as you can, please tell me which of the
following functions has UB.

>>
>Both of them. (Both do illegal pointer comparisons.)

>
Are you saying that because that's your "quickly as
you can" response, or because you genuinely think this
to be true?

No, you're right - I read the article too quickly. Apologies.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[CBFalconer]

Re: Dereference an array pointer... UB?

Kaz Kylheku wrote:

"Tomás Ó hÉilidhe" <t...@lavabit.c omwrote:
>

.... snip ...

>

>Considering the syntax of the language, then we definitely do
>dereference an invalid pointer... but if we consider the
>mechanics of the language, then we know that nothing "happens"
>when we dereference a pointer to an array, because arrays are
>dealt with in terms of pointers.

>
We could also argue that ``nothing'' happens when you merely
increment a pointer out of bounds.

Piggybacking. Nonsense. Dereferencing an invalid pointer means
attempting to access memory that is not available to you. A system
that detects all errors should crash. Many won't.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

[Chris Torek]

Re: Dereference an array pointer... UB?

In article <8763wukmam.fsf @kvetch.smov.or g>
Keith Thompson <kst-u@mib.orgwrote:

>Here's something to chew on. It probably says something about the
>original question, but I'm not sure what.
>
>int main(void)
>{
struct s {
int x;
int y[2];
} ;
volatile struct s obj = { 10, { 20, 30 } };
>
obj; /* Computes and discards the value of obj.
Must access obj.x, obj.y[0], and obj.y[1]. */

This seems reasonable, although I would be unsurprised to find
compilers that did not in fact access the three "int"s.

obj.x; /* Computes and discards the value of obj.x.
Must access obj.x. */

And must not access obj.y[0] and obj.y[1] (I believe).

obj.y; /* Computes and discards the address of obj.y[0].
Must this access obj.y[0] and obj.y[1]?
*May* it do so?
C&V? */

I think the answer to this is "no and no" but I cannot prove it.

If the answer *is* "no and no", I think this guarantees that the
OP's construct (not included in this follow-up) is strictly conforming.

return 0;
>}

--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: gmail (figure it out) http://web.torek.net/torek/index.html