public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: libstdc++/6246: gcc generates code that memleaks
@ 2002-04-12 23:36 Clemens Kirchgatterer
0 siblings, 0 replies; 3+ messages in thread
From: Clemens Kirchgatterer @ 2002-04-12 23:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR libstdc++/6246; it has been noted by GNATS.
From: Clemens Kirchgatterer <clemens@thf.ath.cx>
To: rodrigc@gcc.gnu.org, clemens@thf.ath.cx, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:
Subject: Re: libstdc++/6246: gcc generates code that memleaks
Date: Sat, 13 Apr 2002 08:29:34 +0200
rodrigc@gcc.gnu.org wrote:
> Synopsis: gcc generates code that memleaks
>
> State-Changed-From-To: open->closed
> State-Changed-By: rodrigc
> State-Changed-When: Fri Apr 12 19:02:25 2002
> State-Changed-Why:
> Cannot duplicate with gcc 3.0.4
hi!
hmm, this is very strange, as it is NOT gcc's fault, but mine.
*buf += str.str(); <-- this freazes the buffer and returns a
pointer to it. the caller is now
responsible for freeing it with delete().
so, the testprogramm MUST memleak as it is, independently from
the compiler. can you have a look at it, to make this clear?
thanx & sorry for bothering you!
clemens
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: libstdc++/6246: gcc generates code that memleaks
@ 2002-04-14 18:56 Carlo Wood
0 siblings, 0 replies; 3+ messages in thread
From: Carlo Wood @ 2002-04-14 18:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR libstdc++/6246; it has been noted by GNATS.
From: Carlo Wood <carlo@alinoe.com>
To: Clemens Kirchgatterer <clemens@thf.ath.cx>
Cc: rodrigc@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/6246: gcc generates code that memleaks
Date: Mon, 15 Apr 2002 03:51:05 +0200
On Sat, Apr 13, 2002 at 08:29:34AM +0200, Clemens Kirchgatterer wrote:
> hmm, this is very strange, as it is NOT gcc's fault, but mine.
>
> *buf += str.str(); <-- this freazes the buffer and returns a
> pointer to it. the caller is now
> responsible for freeing it with delete().
No it doesn't, not since 3.0 which is conforming to the standard
and where str() returns a std::string. Use std::stringstream,
not std::strstream.
--
Carlo Wood <carlo@alinoe.com>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: libstdc++/6246: gcc generates code that memleaks
@ 2002-04-12 19:02 rodrigc
0 siblings, 0 replies; 3+ messages in thread
From: rodrigc @ 2002-04-12 19:02 UTC (permalink / raw)
To: clemens, gcc-bugs, gcc-prs, nobody
Synopsis: gcc generates code that memleaks
State-Changed-From-To: open->closed
State-Changed-By: rodrigc
State-Changed-When: Fri Apr 12 19:02:25 2002
State-Changed-Why:
Cannot duplicate with gcc 3.0.4
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6246
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2002-04-15 1:56 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-04-12 23:36 libstdc++/6246: gcc generates code that memleaks Clemens Kirchgatterer
-- strict thread matches above, loose matches on Subject: below --
2002-04-14 18:56 Carlo Wood
2002-04-12 19:02 rodrigc
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).