Discussion:
Can a value of a (nonvolatile) object change without a store into it?
(too old to reply)
Language Lawyer
2018-08-24 02:21:14 UTC
Permalink
[basic.stc]/4:
When the end of the duration of a region of storage is reached, the values of all pointers representing the address of any part of that region of storage become invalid pointer values.

[intro.execution]/6:
An instance of each object with automatic storage duration is associated with each entry into its block. Such an object exists and *retains its last-stored value during the execution of the block and while the block is suspended (by a call of a function or receipt of a signal)*.


The value of a pointer may change without an explicit or implicit store into it, but the [intro.execution]/6 says it can't (at least for objects with automatic storage duration).
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.
Chris Hallock
2018-08-24 05:14:04 UTC
Permalink
Post by Language Lawyer
When the end of the duration of a region of storage is reached, the values
of all pointers representing the address of any part of that region of
storage become invalid pointer values.
An instance of each object with automatic storage duration is associated
with each entry into its block. Such an object exists and *retains its
last-stored value during the execution of the block and while the block is
suspended (by a call of a function or receipt of a signal)*.
The value of a pointer may change without an explicit or implicit store
into it, but the [intro.execution]/6 says it can't (at least for objects
with automatic storage duration).
Maybe a pointer value's classification as being valid or invalid can change
without the value changing?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.
Thiago Macieira
2018-08-24 06:32:56 UTC
Permalink
Post by Chris Hallock
Maybe a pointer value's classification as being valid or invalid can change
without the value changing?
It can.

int *ptr;
{
int i;
ptr = &i; // ptr is valid
*ptr = 42;
}
// ptr is invalid

The above example is what [basic.stc]/4 is referring to. It doesn't say the
pointer value changes. It says that the value becomes invalid.

Now, imagine the code continues as:

int j;
if (ptr == &j)
// ....

The value stored in ptr and the address of j may be the same, depending on how
the compiler organises the stack. But the compiler is allowed to say this
comparison is false, as ptr pointed to a variable whose scope ended and an
invalid pointer value cannot be equal to a valid one.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.
Language Lawyer
2018-08-24 07:06:35 UTC
Permalink
Post by Thiago Macieira
Post by Chris Hallock
Maybe a pointer value's classification as being valid or invalid can change
without the value changing?
It can.
int *ptr;
{
int i;
ptr = &i; // ptr is valid
*ptr = 42;
}
// ptr is invalid
The above example is what [basic.stc]/4 is referring to. It doesn't say the
pointer value changes. It says that the value becomes invalid.
If the value of the pointer does not change, it retains its last-stored value — "pointer to" the int object.
If the value becomes "invalid", then it definitely does not retain its last-stored value, which is "pointer to" the object.
But there was no store into the pointer.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.
'Johannes Schaub' via ISO C++ Standard - Discussion
2018-08-24 13:33:44 UTC
Permalink
All I remember is that there are some intricate wordings about what
constitutes the value of an object pointer. I think that in addition to
being represented as an address or absence of such (null pointer), the
value also consists of an object identity of the pointee (and whether it
points directly or one-past). The "invalid pointer" notion serves to solve
the "pointer to non-existent object" ugliness.

So do you have a way to detect the silent change of value? How does it look
like?
Post by Language Lawyer
Post by Thiago Macieira
Post by Chris Hallock
Maybe a pointer value's classification as being valid or invalid can
change
Post by Thiago Macieira
Post by Chris Hallock
without the value changing?
It can.
int *ptr;
{
int i;
ptr = &i; // ptr is valid
*ptr = 42;
}
// ptr is invalid
The above example is what [basic.stc]/4 is referring to. It doesn't say
the
Post by Thiago Macieira
pointer value changes. It says that the value becomes invalid.
If the value of the pointer does not change, it retains its last-stored
value — "pointer to" the int object.
If the value becomes "invalid", then it definitely does not retain its
last-stored value, which is "pointer to" the object.
But there was no store into the pointer.
--
---
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at
https://groups.google.com/a/isocpp.org/group/std-discussion/.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.
Language Lawyer
2018-08-24 14:16:43 UTC
Permalink
Post by 'Johannes Schaub' via ISO C++ Standard - Discussion
All I remember is that there are some intricate wordings about what
constitutes the value of an object pointer. I think that in addition to
being represented as an address or absence of such (null pointer), the
value also consists of an object identity of the pointee (and whether it
points directly or one-past). The "invalid pointer" notion serves to solve
the "pointer to non-existent object" ugliness.
So do you have a way to detect the silent change of value? How does it look
like?
Without a way to detect the silent change of value you won't believe me that there is a contradiction in the standard?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.
Nathan Ernst
2018-08-24 15:24:07 UTC
Permalink
How is this any different than an vector iterator being potentially
invalidated after an insert (or erase or push_back)? The iterator hasn't
changed, but what it refers to is no longer valid.

Same goes for deleting a pointer:
int* p = new int(0);
delete p;

The pointer p still has a value - the delete doesn't modify p, but you
cannot dereference it as what it points to is no longer valid.

There is no silent change of value. The value hasn't changed. But what the
value *means* has changed.
Post by Language Lawyer
Post by 'Johannes Schaub' via ISO C++ Standard - Discussion
All I remember is that there are some intricate wordings about what
constitutes the value of an object pointer. I think that in addition to
being represented as an address or absence of such (null pointer), the
value also consists of an object identity of the pointee (and whether it
points directly or one-past). The "invalid pointer" notion serves to
solve
Post by 'Johannes Schaub' via ISO C++ Standard - Discussion
the "pointer to non-existent object" ugliness.
So do you have a way to detect the silent change of value? How does it
look
Post by 'Johannes Schaub' via ISO C++ Standard - Discussion
like?
Without a way to detect the silent change of value you won't believe me
that there is a contradiction in the standard?
--
---
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at
https://groups.google.com/a/isocpp.org/group/std-discussion/.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.
Language Lawyer
2018-09-19 21:27:05 UTC
Permalink
Post by Nathan Ernst
How is this any different than an vector iterator being potentially
invalidated after an insert (or erase or push_back)? The iterator hasn't
changed, but what it refers to is no longer valid.
Iterator invalidation is a "high-level" concept.
It could be expressed in terms of program actions.
Although, if an iterator object contains pointers (or is a pointer itself) its invalidation usually comes from the pointer(s) value invalidation.
Post by Nathan Ernst
int* p = new int(0);
delete p;
The pointer p still has a value
Yes, but it became different after the `delete`.
Post by Nathan Ernst
There is no silent change of value. The value hasn't changed. But what the
value *means* has changed.
Again, how it is possible to say that the value hasn't changed if before release of the storage a pointer had the "pointer to" value and after the release it has "invalid pointer" value?

And I don't understand what do you mean under "value means".
For me, the value of an object is what its representation means.
So there is a bit sequence (representation) and its meaning (value).
What is a meaning of the meaning?

http://eel.is/c++draft/basic.types#basic.compound-3.sentence-6
enumerates possible pointer values and
http://eel.is/c++draft/basic.types#basic.compound-3.sentence-9 says:
"The value representation of pointer types is implementation-defined."
There is "value representation" and "value" which I understand as "the meaning of a value representation".

If the [intro.execution]/6 were saying "retains its last-stored representation" instead of "retains its last-stored value" there would be no problem with [basic.stc]/4 changing the values of the pointers: a pointer object was not touched but what its representation means has changed.
The problem is that [intro.execution]/6 clearly says "retains its last-stored value".
Post by Nathan Ernst
Post by Language Lawyer
Post by 'Johannes Schaub' via ISO C++ Standard - Discussion
All I remember is that there are some intricate wordings about what
constitutes the value of an object pointer. I think that in addition to
being represented as an address or absence of such (null pointer), the
value also consists of an object identity of the pointee (and whether it
points directly or one-past). The "invalid pointer" notion serves to
solve
Post by 'Johannes Schaub' via ISO C++ Standard - Discussion
the "pointer to non-existent object" ugliness.
So do you have a way to detect the silent change of value? How does it
look
Post by 'Johannes Schaub' via ISO C++ Standard - Discussion
like?
Without a way to detect the silent change of value you won't believe me
that there is a contradiction in the standard?
--
---
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at
https://groups.google.com/a/isocpp.org/group/std-discussion/.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.
'Johannes Schaub' via ISO C++ Standard - Discussion
2018-08-24 15:31:21 UTC
Permalink
Thanks for making me confirm that I was wrong. If the value does not
silently change, the pointer can still undergo lvalue to rvalue conversion
and you are guaranteed to get the address of the now-dead object (and
whatever that might mean!).

So.. it all comes down to: What is a "store"? Does a store have to happen
by an assignment or initialization? Or can it be induced by any rule? If
the latter, then we would have the apparent contradiction solved. The "last
stored value" would be the transition to the invalid pointer value.

Note that we have a similar change of pointer value when creating a new
object in the storage of another object. If certain conditions are met, any
pointer that referred to the old object will henceafter refer to the new
object.
Post by Language Lawyer
Post by 'Johannes Schaub' via ISO C++ Standard - Discussion
All I remember is that there are some intricate wordings about what
constitutes the value of an object pointer. I think that in addition to
being represented as an address or absence of such (null pointer), the
value also consists of an object identity of the pointee (and whether it
points directly or one-past). The "invalid pointer" notion serves to
solve
Post by 'Johannes Schaub' via ISO C++ Standard - Discussion
the "pointer to non-existent object" ugliness.
So do you have a way to detect the silent change of value? How does it
look
Post by 'Johannes Schaub' via ISO C++ Standard - Discussion
like?
Without a way to detect the silent change of value you won't believe me
that there is a contradiction in the standard?
--
---
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at
https://groups.google.com/a/isocpp.org/group/std-discussion/.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.
Language Lawyer
2018-08-25 01:21:41 UTC
Permalink
Post by 'Johannes Schaub' via ISO C++ Standard - Discussion
Thanks for making me confirm that I was wrong. If the value does not
silently change, the pointer can still undergo lvalue to rvalue conversion
and you are guaranteed to get the address of the now-dead object (and
whatever that might mean!).
So.. it all comes down to: What is a "store"? Does a store have to happen
by an assignment or initialization? Or can it be induced by any rule? If
the latter, then we would have the apparent contradiction solved. The "last
stored value" would be the transition to the invalid pointer value.
Well, if you take such a position, you'll have a hard time trying to explain
how these silent stores interact with volatile and atomic pointers.

For example, do such stores access a volatile pointer object, thus making
such stores observable? Or they are so silent that they change the value
of volatile pointers without making an access? Or they are so silent that
do not change a value of volatile pointers? If so, it would be possible
to restore a valid pointer value from a volatile pointer and one will need
to explain why it may not possible to validly use it.

The same for atomic pointers (here I assume that atomic pointers have the
same values as non-atomic, because I believe the intent of the standard is
that such pointers may be used to make modifications of objects visible
across threads by storing and fetching pointers to objects).
Post by 'Johannes Schaub' via ISO C++ Standard - Discussion
The value of an atomic object M, as determined by evaluation B, shall be
the value stored by some side effect A that modifies M, where B does not
happen before A.
Does the end of the duration of a region of storage lead to side effects
that store the invalid pointer values into all atomic pointers representing
any address in the region of storage? I hope these stores are atomic.
Which memory order flags do they haev?
Post by 'Johannes Schaub' via ISO C++ Standard - Discussion
Note that we have a similar change of pointer value when creating a new
object in the storage of another object. If certain conditions are met, any
pointer that referred to the old object will henceafter refer to the new
object.
Post by Language Lawyer
Post by 'Johannes Schaub' via ISO C++ Standard - Discussion
All I remember is that there are some intricate wordings about what
constitutes the value of an object pointer. I think that in addition to
being represented as an address or absence of such (null pointer), the
value also consists of an object identity of the pointee (and whether it
points directly or one-past). The "invalid pointer" notion serves to
solve
Post by 'Johannes Schaub' via ISO C++ Standard - Discussion
the "pointer to non-existent object" ugliness.
So do you have a way to detect the silent change of value? How does it
look
Post by 'Johannes Schaub' via ISO C++ Standard - Discussion
like?
Without a way to detect the silent change of value you won't believe me
that there is a contradiction in the standard?
--
---
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at
https://groups.google.com/a/isocpp.org/group/std-discussion/.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.
Language Lawyer
2018-09-19 21:42:29 UTC
Permalink
Post by Language Lawyer
When the end of the duration of a region of storage is reached, the values of all pointers representing the address of any part of that region of storage become invalid pointer values.
An instance of each object with automatic storage duration is associated with each entry into its block. Such an object exists and *retains its last-stored value during the execution of the block and while the block is suspended (by a call of a function or receipt of a signal)*.
The value of a pointer may change without an explicit or implicit store into it, but the [intro.execution]/6 says it can't (at least for objects with automatic storage duration).
BTW, I didn't found this by myself.
There are at least 2 DRs [1,2] for the ISO C standard discussing the same issue.

The C standard is either implies action (store) on a distance or managed to put 2 mutually contradictory statements into ONE PARAGRAPH
https://port70.net/~nsz/c/c11/n1570.html#6.2.4p2:
The lifetime of an object is the portion of program execution during which storage is guaranteed to be reserved for it. An object exists, has a constant address, and *retains its last-stored value throughout its lifetime*. If an object is referred to outside of its lifetime, the behavior is undefined. *The value of a pointer becomes indeterminate when the object it points to (or just past) reaches the end of its lifetime*.

[1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm
[2] http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_451.htm
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.
Continue reading on narkive:
Loading...