Jonathan Wakely <redi at gcc dot> changed:

           What    |Removed                     |Added
             Status|WAITING                     |RESOLVED
         Resolution|---                         |INVALID

--- Comment #7 from Jonathan Wakely <redi at gcc dot> ---
OK I've finished debugging this horribly obfuscated program, and this is not a
compiler bug.

This is copy-initialization:

  estrbuf copybuf1 = varbuf4.as_const();

That means it's equivalent to this:

  estrbuf copybuf1 = estrbuf(varbuf4.as_const());

This constructs a temporary strbuf which has the expected value (0x80000000)
but then tries to copy-construct another estrbuf. Your copy constructor cannot
be used to copy temporaries, because you declared it so it only works for

  inline xstrbuf( xstrbuf& s )

so instead the temporary gets converted to its base class (via slicing) and
calls this constructor:

  inline xstrbuf( base_str s )

and that constructor sets bufParams to:

     bufParams = s.length | xstrbuf_bufUserAllocatedBit;

Which explains the unwanted 0xb in the value 8000000b, it comes from s.length

In the second case you use direct-initialization:

  estrbuf copybuf2( varbuf4.as_const() );

so there is no temporary, no slicing, and no copy that gets s.length in the

You should fix your copy constructor to accept const-lvalues, and avoid
slicing, (and stop misusing the pure attribute, and remove the useless register
keywords, and use more whitespace to help readability, and stop using so many
macros, ...)

Reply via email to