Topic: Uninitialized rvalue


Author: dag.henriksson@quidsoft.se
Date: 2000/08/09
Raw View
In article <ufLu7xBlr8j5Ewgm@robinton.demon.co.uk>,
  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
> In article <8mn6p7$c9q$1@cubacola.tninet.se>, Dag Henriksson
> <dag.henriksson@quidsoft.se> writes
> >What will happen when executing the code above is defined. The
content of
> >A().a (what ever it is) will be copied to b.
>
> Including when that content is a trap-value? Since when has reading
> uninitialised storage (other than for a char) been defined behaviour?

This is exactly why I think the standard is wrong.
If you had followed the discussion, you would have seen that we totally
agree.

I Wrote:
> > > I cannot find anything in the standard that forbids this.
> ... but the intention must be not to allow
> this. Since loading an illegal value into a register can cause a
hardware
> trap, this ought to be banned.

-- Dag Henriksson


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: wmm@fastdial.net
Date: 2000/08/08
Raw View
In a previous article,  "Dag Henriksson"  <dag.henriksson@quidsoft.se>
writes:
>struct A
>{
>  A() {}
>  int a;
>};
>int b = A().a;
>
>Here, no lvalue-to-rvalue conversion takes place.
>
>I cannot find anything in the standard that forbids this. Have I missed
>something or is this a defect in the standard?

I think there's a good chance this is a defect.  There are a
couple of other potential problems with 4.1p1 as well, so I
will add this to the Core Language issues list.  Thanks for
pointing it out.

-- William M. Miller


     -----  Posted via NewsOne.Net: Free Usenet News via the Web  -----
     -----  http://newsone.net/ --  Discussions on every subject. -----
   NewsOne.Net prohibits users from posting spam.  If this or other posts
made through NewsOne.Net violate posting guidelines, email abuse@newsone.net

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: Ron Natalie <ron@sensor.com>
Date: 2000/08/08
Raw View

Dag Henriksson wrote:
>
> What will happen when executing the code above is defined. The content of
> A().a (what ever it is) will be copied to b. None of the nasty things with
> undefined behaviour will happen. The hard disk will not be formatted, my
> boss will not receive a malicious mail and the daemons will stay in my
> nose...
>

The standard says they have "indeterminate" initial value.  This means that
while the code is not "undefined", you should be very careful about doing
anything with the value.  Int is probably a safe (but pointless gesture),
however, make the type of a "double" and you'll have more fun.  The assigment
may cause a floating point trap if the "indeterminate" type is a signalling
out of bounds value.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 2000/08/08
Raw View
In article <8mn6p7$c9q$1@cubacola.tninet.se>, Dag Henriksson
<dag.henriksson@quidsoft.se> writes
>What will happen when executing the code above is defined. The content of
>A().a (what ever it is) will be copied to b.

Including when that content is a trap-value? Since when has reading
uninitialised storage (other than for a char) been defined behaviour?



Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 2000/08/04
Raw View
In article <8mc91i$k1j$1@cubacola.tninet.se>, Dag Henriksson
<dag.henriksson@quidsoft.se> writes
>"Anthony Williams" <anthony_w@my-deja.com> wrote in message
>news:8mbad9$b0m$1@nnrp1.deja.com...
>> >   "Dag Henriksson" <dag.henriksson@quidsoft.se> wrote:
>> > > struct A
>> > > {
>> > >   A() {}
>> > >   int a;
>> > > };
>> > > int b = A().a;
>> > > I cannot find anything in the standard that forbids this.
>>
>> The behaviour is not undefined or forbidden, but well-defined.
>
>That's how I read the standard too, but the intension must be not to allow
>this. Since loading an illegal value into a register can cause a hardware
>trap, this ought to be banned.

Exactly how is it 'defined behaviour' to read uninitialised storage?


Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: "Dag Henriksson" <dag.henriksson@quidsoft.se>
Date: 2000/08/07
Raw View
"Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message
news:IppHWlCr4qi5EwuK@robinton.demon.co.uk...
> >> >   "Dag Henriksson" <dag.henriksson@quidsoft.se> wrote:
> >> > > struct A
> >> > > {
> >> > >   A() {}
> >> > >   int a;
> >> > > };
> >> > > int b = A().a;

> Exactly how is it 'defined behaviour' to read uninitialised storage?

What will happen when executing the code above is defined. The content of
A().a (what ever it is) will be copied to b. None of the nasty things with
undefined behaviour will happen. The hard disk will not be formatted, my
boss will not receive a malicious mail and the daemons will stay in my
nose...

But as I wrote earlier, I think the standard is wrong here, or I haven't
found the paragraph that makes this code undefined.

-- Dag Henriksson




---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: "Dag Henriksson" <dag.henriksson@quidsoft.se>
Date: 2000/08/02
Raw View
We all know that an uninitialized lvalue cannot be used as an rvalue.

int a;
int b = a;

This is not allowed because the lvalue-to-rvalue conversion is not allowed
for uninitialized objects (4.1p1).

But what if the object already is an rvalue?

struct A
{
  A() {}
  int a;
};
int b = A().a;

Here, no lvalue-to-rvalue conversion takes place.

I cannot find anything in the standard that forbids this. Have I missed
something or is this a defect in the standard?

-- Dag Henriksson



---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: Roger Orr <roger_orr@my-deja.com>
Date: 2000/08/03
Raw View
In article <8m8u4f$gii$1@cubacola.tninet.se>,
  "Dag Henriksson" <dag.henriksson@quidsoft.se> wrote:
> We all know that an uninitialized lvalue cannot be used as an rvalue.
[snip]
> But what if the object already is an rvalue?
>
> struct A
> {
>   A() {}
>   int a;
> };
> int b = A().a;
>
> Here, no lvalue-to-rvalue conversion takes place.
>
> I cannot find anything in the standard that forbids this.

It's "undefined" rather than "forbidden" :-)

> Have I
missed
> something or is this a defect in the standard?
>
> -- Dag Henriksson
>

I can't see anything either.  I wonder whether it is sufficient to
expand 4.1p1 to handle temporaries or are there other ways to circumvent
4.1p1 [I couldn't come up with one]?

Roger.
--
MVP in C++ for Brainbench at http://www.brainbench.com


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: Anthony Williams <anthony_w@my-deja.com>
Date: 2000/08/03
Raw View
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In article <8m9ehl$tfm$1@nnrp1.deja.com>,
  Roger Orr <roger_orr@my-deja.com> wrote:
> In article <8m8u4f$gii$1@cubacola.tninet.se>,
>   "Dag Henriksson" <dag.henriksson@quidsoft.se> wrote:
> > We all know that an uninitialized lvalue cannot be used as an
rvalue.
> [snip]
> > But what if the object already is an rvalue?
> >
> > struct A
> > {
> >   A() {}
> >   int a;
> > };
> > int b = A().a;
> >
> > Here, no lvalue-to-rvalue conversion takes place.
> >
> > I cannot find anything in the standard that forbids this.
>
> It's "undefined" rather than "forbidden" :-)

The behaviour is not undefined or forbidden, but well-defined. b is
initialized
to the value of the a member of the temporary. Since the constructor of
A
doesn't initialize A::a, its _value_ is unspecified. This unspecified
value is
what is used to initialize b.

See 12.6.2p4:

After the call to a constructor for class X has completed, if a member
of X is
neither specified in the
constructor   s mem-initializers, nor default-initialized, nor
initialized during
execution of the body of the
constructor, the member has indeterminate value.

Anthony
- --
alink@anthonyw.cjb.net -- Questions relating to ALINK
anthony@anthonyw.cjb.net  -- Non-ALINK questions
anthonyw.cjb.net -- ALINK home page
PGP Key at: i3.yimg.com/3/c7e5ee24/g/68fc2307.asc

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.1 for non-commercial use <http://www.pgp.com>
Comment: PGP Key at: http://i3.yimg.com/3/c7e5ee24/g/68fc2307.asc

iQA/AwUBOYks3pvw+P4cG5rVEQIwGQCg/aII8xm88qisKCA5KJeKjK+q8+EAoMvJ
uPIlMPfaqwpe56uUahOtUMdt
=eWSM
-----END PGP SIGNATURE-----


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]






Author: "Dag Henriksson" <dag.henriksson@quidsoft.se>
Date: 2000/08/03
Raw View
"Anthony Williams" <anthony_w@my-deja.com> wrote in message
news:8mbad9$b0m$1@nnrp1.deja.com...
> >   "Dag Henriksson" <dag.henriksson@quidsoft.se> wrote:
> > > struct A
> > > {
> > >   A() {}
> > >   int a;
> > > };
> > > int b = A().a;
> > > I cannot find anything in the standard that forbids this.
>
> The behaviour is not undefined or forbidden, but well-defined.

That's how I read the standard too, but the intension must be not to allow
this. Since loading an illegal value into a register can cause a hardware
trap, this ought to be banned.

-- Dag Henriksson


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]