Topic: lvalue-to-rvalue and sizeof
Author: fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson)
Date: 1997/08/18 Raw View
sanjayp@ddi.com writes:
>I found under 4.1 [conv.lval] para 2:
>
>...When an lvalue-to-rvalue conversion occurs within the operand of
>sizeof(5.3.3) the value contained in the referenced object is not
>accessed,....
>
>And under 5.3.3 [expr.sizeof] para 4:
>
>The lvalue-to-rvalue [conv.lval], ... standard conversions are not
>applied to the operand of sizeof.
>
>Is this an inconsistency? In any case, what is the need for putting
>the restriction in [expr.sizeof] with respect to lvalue-to-rvalue
>conversion?
The wording does appear to be inconsistent.
I think the intent is to cover cases such as
int *p = 0;
sizeof(*p); // OK, because *p is not evaluated.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]
Author: Tom Payne <thp@cs.ucr.edu>
Date: 1997/08/18 Raw View
sanjayp <sanjayp@ddi.com> writes:
|> Hi,
|> I found under 4.1 [conv.lval] para 2:
|> ...When an lvalue-to-rvalue conversion occurs within the operand
|> of sizeof(5.3.3) the value contained in the referenced object is not
|> accessed,....
|> And under 5.3.3 [expr.sizeof] para 4:
|> The lvalue-to-rvalue [conv.lval], ... standard conversions are
|> not applied to the operand of sizeof.
|> Is this an inconsistency?
Not "inconsistent," but the sentence from 5.3.3 para 4 implies that
the sentence from 4.1 para 2 is *vacuuous*. It is important that say
a dangling pointer not be accessed when its sizeof is computed, else
undefined behavior would follow, unnecessarily.
Things are a bit delicate when the operand is a reference.
Intuitively, the behavior of greatest regularity would be to
dereference the reference but not access its referrent. I think that
dereferencing a dangling reference, however, provokes undefined
behavior, just like a dangling pointer. I assume that's why the
Committee has tried to define sizeof(Widget), where Widget is a
reference type, to be the size of a Widget's reference.
Tom Payne
---
[ comp.std.c++ is moderated. To submit articles: try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: "Sanjay" <sanjayp@ddi.com>
Date: 1997/08/20 Raw View
Fergus Henderson <fjh@murlibobo.cs.mu.OZ.AU> wrote in article
<5t79cm$bdo@mulga.cs.mu.OZ.AU>...
> sanjayp@ddi.com writes:
>
> >I found under 4.1 [conv.lval] para 2:
> >
> >...When an lvalue-to-rvalue conversion occurs within the operand of
> >sizeof(5.3.3) the value contained in the referenced object is not
> >accessed,....
> >
> >And under 5.3.3 [expr.sizeof] para 4:
> >
> >The lvalue-to-rvalue [conv.lval], ... standard conversions are not
> >applied to the operand of sizeof.
> >
> >Is this an inconsistency? In any case, what is the need for putting
> >the restriction in [expr.sizeof] with respect to lvalue-to-rvalue
> >conversion?
>
> The wording does appear to be inconsistent.
> I think the intent is to cover cases such as
>
> int *p = 0;
> sizeof(*p); // OK, because *p is not evaluated.
I know that the operand of the sizeof operator, if it happens
to be an expression is not evaluated. That means the compiler
does not generate code for (nor does it try to evaluate at compile
time) the expression.
But the compiler still has to semantic-check and type-
analyze the expression to arrive at the type of the expression,
so that it can compute its size. In computing the type of this
expression the standard forbids lvalue-to-rvalue conversion to
the operand.
Someone pointed out that 5.3.3 says "lvalue-to-rvalue
conversions.... are not applied TO the operand of sizeof.". And
4.1 says "...When an lvalue-to-rvalue conversion occurs WITHIN
the operand of sizeof..".
So may be this WITHIN vs TO does not make it
inconsistent? Is that true?
Sanjay
---
[ comp.std.c++ is moderated. To submit articles: try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: sanjayp@ddi.com
Date: 1997/08/14 Raw View
Hi,
I found under 4.1 [conv.lval] para 2:
...When an lvalue-to-rvalue conversion occurs within the operand of sizeof(5.3.3) the value contained in the referenced object is not accessed,....
And under 5.3.3 [expr.sizeof] para 4:
The lvalue-to-rvalue [conv.lval], ... standard conversions are not applied to the operand of sizeof.
Is this an inconsistency? In any case, what is the need for putting the restriction in [expr.sizeof] with respect to lvalue-to-rvalue conversion? Are there any cases where sizeof would give a different value because of lvalue-to-rvalue conversion?
Sanjay
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]
Author: schwab@issan.informatik.uni-dortmund.de (Andreas Schwab)
Date: 1997/08/15 Raw View
sanjayp <sanjayp@ddi.com> writes:
|> Hi,
|> I found under 4.1 [conv.lval] para 2:
|> ...When an lvalue-to-rvalue conversion occurs within the operand of sizeof(5.3.3) the value contained in the referenced object is not accessed,....
|> And under 5.3.3 [expr.sizeof] para 4:
|> The lvalue-to-rvalue [conv.lval], ... standard conversions are not applied to the operand of sizeof.
|> Is this an inconsistency?
I don't think so. The lvalue-to-rvalue conversion can occur as part of a
sub-expression, whereas [expr.sizeof] only talks about the operand itself.
--
Andreas Schwab "And now for something
schwab@issan.informatik.uni-dortmund.de completely different"
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]