Re: UB while dealing with invalid raw pointers, the std::uninitialized_fill
case
Alf P. Steinbach /Usenet <alf.p.steinbach+usenet@gmail.com>, on
03/09/2010 13:28:40, wrote:
* Francesco S. Carta, on 03.09.2010 12:52:
Hi there,
as far as I've been able to understand, if a raw pointer contains an
invalid
value (that is, it does not point to any valid object of the type it is a
pointer to) then some of the actions performed on these pointers will
lead to UB.
Hm, well you need to define "invalid" more precisely, e.g. as "is not
valid". ;-) Or even more precisely, "can not be dereferenced without
UB". For example, 0 is a valid pointer value, as is 1+p where p points
to the last element in an array.
Neither C++98 nor C++0x does, as far as I know, define "invalid
pointer", but C++0x defines "valid pointer" as pointing to a byte in
memory or being zero, in C++0x ?2.9.2/3. The definition in C++0x is
perhaps too permissive. If taken literally the validity of a pointer
would in general not be deducible but would depend on whether the
address in question had been remapped by the HW, e.g. p would be /valid/
immediately after delete p unless the delete affected the validity of
the address itself (e.g. by changing paging or segment setup).
But OK...
OK, I've read your self-follow-up, just for the records. Correctly
defining an invalid pointer seems to be impossible, but we have some
agreed cases of valid and invalid pointer values:
- the null-pointer value is a valid and non-dereferenceable value;
- the address of a valid object is a valid pointer value;
- the address of a valid object becomes an invalid pointer value after
the object gets destroyed;
- the value of an uninitialized pointer is an invalid pointer value and,
according to the following, it also is a singular pointer value:
[lib.iterator.requirements] p. 5
"[...] Iterators can also have singular values that are not associated
with any container. [Example: After the declaration of an uninitialized
pointer x (as with int* x;), x must always be assumed to have a singular
value of a pointer. ] Results of most expressions are undefined for
singular values; the only exception is an assignment of a non-singular
value to an iterator that holds a singular value. [...]"
....and as the above states, the only thing that can be done with a
singular pointer value is to assign a non-singular pointer value to it.
Following the informal reasoning above, we can safely assign zero or the
address of a valid object to that invalid pointer (i.e. that pointer
containing a singular value).
Fast forward now...
As it seems, two actions in particular should be safe and well defined:
- zeroing the invalid pointer;
- assigning a valid value to the invalid pointer;
One issue that has been recently raised in this group is about storing
invalid
raw pointers into a container such as std::vector; the rationale that
led to
define it as a potential source of UB is about the lvalue to rvalue
conversion
that will be performed on those raw pointers during internal
reallocations of
the container.
Since the only significant action that gets performed during the
reallocation is
to copy such invalid pointer values from a storage to another, it
should boil
down to something equivalent to this:
int* p = new int;
delete p;
Now "p" contains and invalid value.
int* q = p;
During the above assignment, an lvalue to rvalue conversion is
performed on "p",
leading to undefined behavior.
Now my question is, would the following test also lead to an lvalue to
rvalue
conversion on "p", therefore leading to UB?
int* p = new int;
delete p;
int* q = new int;
if(q != p) {
//...
}
Yes, this invokes rvalue conversion and UB.
OK about the conversion, still not convinced about the UB.
Fast forward once more...
If that's the case, then any uninitialized_fill performed on a storage
area of
raw pointers will lead to UB, as the Standard depicts, as expected
effect, the
fact of comparing two invalid pointers:
[citation formatted for presentation]
20.4.4.2 uninitialized_fill [lib.uninitialized.fill]
template <class ForwardIterator, class T>
void uninitialized_fill(ForwardIterator first,
ForwardIterator last,
const T& x);
1 Effects:
for (; first != last; ++first)
new (static_cast<void*>(&*first))
typename iterator_traits<ForwardIterator>::value_type(x);
Huh, no.
'first' and 'last' here are not invalid pointers: if pointers, then they
point /to/ the area to be filled.
Here we come to the point, assume this program, which should be
well-defined and well-behaving:
//-------
#include <iostream>
#include <memory>
using namespace std;
int main() {
size_t n = 4;
int* start = static_cast<int*>(
operator new(n * sizeof(int))
);
int* end = start + n;
uninitialized_fill(start, end, 42);
for(int* i = start; i < end; ++i) {
cout << *i << endl;
}
operator delete(start);
return 0;
}
//-------
By the time "start" gets initialized, it points to an uninitialized
storage area big enough to hold an int, but since that storage is
uninitialized, the pointer is currently invalid (we cannot dereference
it without invoking UB). "end" is an invalid pointer too.
Let's now enter the uninitialized_fill template function.
It gets called with this pseudo-signature:
uninitialized_fill<int*, int>(...)
which means that in the "Expected" section cited above, we have:
for (; first != last; ++first)
where "first == start" and "last == end", and all of them are of type
"class ForwardIterator = int*"
Following from all the above, we should have a standard algorithm that
invokes UB by comparing two invalid pointers.
Where is my reasoning flawed?
Would all the above mean that we shouldn't really worry about UB when
dealing
with invalid pointers into standard containers as long as we don't
dereference
such invalid pointers,
Formally you invoke UB when a vector containing invalid pointers is
destroyed.
That's because a simplistic implementation may iterate over the vector
contents and do pseudo destructor calls on the pointers (or it can do
anything at all).
In practice it's not anything I'd worry about, because leaving a vector
with invalid pointers is common practice, so implementations have to not
crash on that. However, to play nice, I guess one should always zero a
pointer in a vector (or other container) after making it invalid. Just
making sure.
and accordingly, would that mean that the standard needs
to be modified to state these actions (copying and comparing of invalid
pointers) as well-defined?
I dont't think so.
If the standard was all too clear about everything then we'd have
nothing to discuss.
That doesn't really seem a good reason to keep a self-contradicting
standard (if it really is the case). I'd like to think that you're just
kidding :-)
--
FSC - http://userscripts.org/scripts/show/59948
http://fscode.altervista.org - http://sardinias.com