[Bug libstdc++/11584] ios::iword() fails to zero-initialize storage on failure

["jlquinn at optonline dot net" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From jlquinn at optonline dot net  2003-12-30 20:21 -------
(In reply to comment #6)
> Subject: Re:  ios::iword() fails to zero-initialize storage on failure
> 
> On Wed, Sep 17, 2003 at 11:45:29PM -0000, bkoz at gcc dot gnu dot org wrote:
> > On closer examination, I don't think this is a bug. 
> 
> I don't agree. See below.
> 
> > For one thing:
> > 
> >     int i = std::ios::xalloc();
> >     std::cout.iword (i) = 0xdeadbeef;
> >     long l = std::cout.iword (i);
> >     l == 0xdeadbeef;
> > is valid, based on the fact that the index is the same (regardless of the
> > replacement operator new). 
> 
> First note that iword must try to realloc the array if it is called
> with an out of bounds index. This is what happens here and the case
> where iword succeeds seems to be standard conforming.
> 
> But the bug report is about the case where iword _fails_ to extend the
> array. 27.4.2.5[3] clearly states for this case:
> 
> | Returns: [...] On failure, a valid long& initialized to 0.
> 
> The comparions in the above testcase MUST be false in the case where
> iword can't allocate enough memory. The reason is that both iword calls
> fail and consequently both calls should return 0.

It seems the source of the disagreement here is the interpretation of
"initialized to 0" in the standard.  If iword(invalid) must always return a
reference to a long equal to 0, then Christian is correct and the above code
snippet should fail.  If iword(invalid) only has to return a reference to a long
that was assigned to 0 the *first* time it was referenced, then Benjamin is
correct and the above piece of code should always work.

I tend to believe Christian's interpretation, but suspect the standard is a bit
ambiguous here.

Jerry

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11584