Re: copy smaller array into bigger array?
On Aug 17, 7:44 pm, Francesco <entul...@gmail.com> wrote:
On 17 Ago, 10:13, James Kanze <james.ka...@gmail.com> wrote:
On Aug 16, 5:37 pm, Francesco <entul...@gmail.com> wrote:
In this regard, the standard bases itself on C90. In C90,
the question was actually raised, and answered by the C
committee---it is undefined behavior. The authors of the C
standard didn't like this, so in C99, they introduced a
special case:
The unary & operator returns the address of its operand.
If the operand has type =91=91type'', the result has type
=91=91pointer to type''. If the operand is the result of a
unary * operator, neither that operator nor the &
operator is evaluated and the result is as if both were
omitted, except that the constraints on the operators
still apply and the result is not an lvalue. Similarly,
if the operand is the result of a [] operator, neither
the & operator nor the unary * that is implied by the []
is evaluated and the result is as if the & operator were
removed and the [] operator were changed to a +
operator. Otherwise, the result is a pointer to the
object or function designated by its operand.
The special case is present because such an expression would
otherwise be undefined behavior---C++ doesn't have this
special case.
[...]
The standard very clearly says that v[4] is the exact equivalent
of *(v + 4). Period. Unlike the C standard, it doesn't make
any exceptions. The standard also says that the result of a
unary * _must_ designate an object, and in this case, there is
no object at v+4, so the expression is undefined behavior.
FWIW, this fact wasn't recognized when the C standard was
originally adopted, which means that it wasn't realized when
much of the C++ standard was being written (and perhaps when
Stroustrup wrote the text you site). Once the problem was
pointed out, the C committee, in a response to a DR or in a
request for interpretation, recognized that as the standard
stood, it was undefined behavior---by that time, they were
already in the process of creating C99, so they added the
special text to remove the undefined behavior. I seem to
remember a little bit of discussion in the C++ committee as
to whether C++ should take the same steps, but in the end,
it didn't. (One of the arguments, IIRC, was that
programmers shouldn't use this form anyway, since in
something like:
std::vector< int > v( 4 ) ;
int* p3 = &v[ 4 ] ;
it is also undefined behavior, and in a checking
implementation, will cause a fatal error. And I think it's
impossible to implement a checking implementation where this
wouldn't be the case; vector<>::operator[] would have to
return a proxy which overloaded operator&... and also
operator. .)
Your post is really interesting, I'm happy to have stomped on
such issue, being that it still seems to be debated.
It's not still being debated. It was debated by the C
committee: they made a definite statement that
&array[onePastTheEnd] is undefined behavior, and made a change
in the standard to allow it. After that change in C, there was
a little discussion about propagating it to C++, but on the
whole, I think the consensus was that it wasn't worth it,
perhaps based on the fact that the C++ committee expects people
to use vector, and not C style arrays, and that it isn't
reasonably possible to make it work with vector.
Now please take a look to these passages I extracted from
[N2914=09-0104] - by the way, is this the last normative
reference? I hope I didn't mistake the meaning of "working
draft" and "current draft" :-/ If I mistaken it, please
somebody point me out which is the document number I must get.
N2914 is, I think, the latest working draft (unless there is a
later one I missed---the "latest working draft" is constantly
changing). It certainly is *not* the current standard, and
differs from it in a large number of ways. To my knowledge,
however, nothing has changed concerning this issue since C++98.
----------------------
4 [conv] / 5
There are some contexts where certain conversions are suppressed. For
example, the lvalue-to-rvalue conversion is not done on the operand of
the unary & operator.
5.3.1 [expr.unary.op] / 3
The result of the unary & operator is a pointer to its operand.
5.7 [expr.add] / 6
Unless both pointers point to elements of the same array object, or
one past the last element of the array object, the behavior is
undefined. 78 <- superscript, for the following footnote:
[same page, footnote]
78) [...] an implementation need only provide one extra byte (which
might overlap another object in the program) just after the end of the
object in order to satisfy the =93one past the last element=94
requirements.
8.3.4 [dcl.array] / 6
Except where it has been declared for a class (13.5.5), the subscript
operator [] is interpreted in such a way that E1[E2] is identical to *
((E1)+(E2)).
24.2 [iterator.concepts] / 6
[...] a regular pointer to an array guarantees that there is a pointer
value pointing past the last element of the array, [...]
---------------------------------
Most of this is irrelevant. The unary operator * results in
undefined behavior unless the dereferenced pointer designates an
object: "the result is an lvalue referring to the object or function
to
which the expression points". That's all we have concerning the
semantics, so if the expression doesn't point to an object,
behavior is undefined. No later operations on the expression
can undo the undefinedness.
The footnote #78 seems to tell that there will actually be something
at that address.
Footnotes aren't normative, and the footnote in question says
just the opposite---that there is no need for an object of the
correct type to be present. (The footnote is misleading,
however, since there is not even a need for the extra byte
unless the system traps invalid pointers; none that I know of
do.)
Also 4 [conv] / 5 seems the same exception introduced by C99, am I
right?
Not at all. First, of course, the text you cite is a
non-normative note. And it doesn't really make much
sense---conversions aren't "suppressed", they simply aren't done
unless necessary. The lvalue to rvalue conversion only occurs
if an lvalue expression is used in a context which requires an
rvalue. There are lots of places it doesn't occur: on the left
side of an assignment, for starters.
And of course, that's totally irrelevant here; I suggested that
a better way of specifying the C exception might be to limit the
undefined behavior to lvalue to rvalue conversions and attempts
to modify the object through the lvalue, but neither standard
actually takes this route, and C++ doesn't have the C exception.
The unary * operator (for built-in types) must refer to an
object of the correct type, or the behavior is undefined (since
the standard doesn't define it, see =A71.3.13).
And that's all. You can't get around that---the C standard
creates a specific exception if (and only if) the expression is
immediately the operand of a & operator, but C++ doesn't have
this exception.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34