* in_avail() bug not fixed in 3.0.3
@ 2001-12-14 8:05 David Rasmussen
2001-12-14 10:26 ` Alexandre Oliva
0 siblings, 1 reply; 6+ messages in thread
From: David Rasmussen @ 2001-12-14 8:05 UTC (permalink / raw)
To: gcc
The in_avail() bug described in GNATS PR# 3647, has not been fixed. The PR
was closed, and marked "fixed", but I have just downloaded the pre-release
gcc-3.0.3-20011213, mentioned by Mark Mitchell. I have built it on cygwin,
successfully, and tried to compile the code from the PR:
#include <iostream>
using namespace std;
int main()
{
cout << cin.rdbuf()->in_avail() << endl;
}
This call should immediately return 0, but it hangs, until enter is pressed,
and then returns 1, which is then written.
How come the bug was marked fixed, when it isn't fixed?
/David
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: in_avail() bug not fixed in 3.0.3
2001-12-14 8:05 in_avail() bug not fixed in 3.0.3 David Rasmussen
@ 2001-12-14 10:26 ` Alexandre Oliva
2001-12-14 11:32 ` Joe Buck
0 siblings, 1 reply; 6+ messages in thread
From: Alexandre Oliva @ 2001-12-14 10:26 UTC (permalink / raw)
To: David Rasmussen; +Cc: gcc
On Dec 14, 2001, "David Rasmussen" <pinkfloydhomer@yahoo.com> wrote:
> How come the bug was marked fixed, when it isn't fixed?
It may well have only been fixed in mainline, in case the fix was too
involved for a minor release such as 3.0.3. For example, it might
require breaking binary compatibility with 3.0.x, which is a major NO
for 3.0.3.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: in_avail() bug not fixed in 3.0.3
2001-12-14 10:26 ` Alexandre Oliva
@ 2001-12-14 11:32 ` Joe Buck
2001-12-14 11:45 ` Phil Edwards
0 siblings, 1 reply; 6+ messages in thread
From: Joe Buck @ 2001-12-14 11:32 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: David Rasmussen, gcc
On Dec 14, 2001, "David Rasmussen" <pinkfloydhomer@yahoo.com> wrote:
> > How come the bug was marked fixed, when it isn't fixed?
Alexandre Oliva writes:
> It may well have only been fixed in mainline, in case the fix was too
> involved for a minor release such as 3.0.3. For example, it might
> require breaking binary compatibility with 3.0.x, which is a major NO
> for 3.0.3.
I'm sure that this is the case, but it does point out a problem: we
don't have a way of querying GNATS to find which bugs fall in this
category (fixed for 3.1 but not for 3.0.x). For a given bug, one can
read the audit trail, but even then it might not be clear; I'm not
sure we're being consistent about updating GNATS when a bug fix is
back-ported, for example.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: in_avail() bug not fixed in 3.0.3
2001-12-14 11:32 ` Joe Buck
@ 2001-12-14 11:45 ` Phil Edwards
2001-12-14 12:05 ` Joe Buck
0 siblings, 1 reply; 6+ messages in thread
From: Phil Edwards @ 2001-12-14 11:45 UTC (permalink / raw)
To: Joe Buck; +Cc: Alexandre Oliva, David Rasmussen, gcc
On Fri, Dec 14, 2001 at 11:27:06AM -0800, Joe Buck wrote:
> On Dec 14, 2001, "David Rasmussen" <pinkfloydhomer@yahoo.com> wrote:
> > > How come the bug was marked fixed, when it isn't fixed?
>
> Alexandre Oliva writes:
> > It may well have only been fixed in mainline, in case the fix was too
> > involved for a minor release such as 3.0.3. For example, it might
> > require breaking binary compatibility with 3.0.x, which is a major NO
> > for 3.0.3.
>
> I'm sure that this is the case,
I'm almost certain that it was.
> but it does point out a problem: we
> don't have a way of querying GNATS to find which bugs fall in this
> category (fixed for 3.1 but not for 3.0.x).
This is YARTTOG[*]. I haven't seen any other bug-tracking system
which offers this specific behavior ("fixed in release X byt not in Y" yet.
Bugzilla has a field for "fix this bug by release X". I don't think the
Debian BTS has any such field either.
Phil
[*] Yet Another Reason To Throw Out GNATS
--
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace. We seek
not your counsel, nor your arms. Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen. - Samuel Adams
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: in_avail() bug not fixed in 3.0.3
2001-12-14 12:05 ` Joe Buck
@ 2001-12-14 12:05 ` Joseph S. Myers
0 siblings, 0 replies; 6+ messages in thread
From: Joseph S. Myers @ 2001-12-14 12:05 UTC (permalink / raw)
To: Joe Buck; +Cc: Phil Edwards, Alexandre Oliva, David Rasmussen, gcc
On Fri, 14 Dec 2001, Joe Buck wrote:
> Phil Edwards writes:
> > This is YARTTOG[*]. I haven't seen any other bug-tracking system
> > which offers this specific behavior ("fixed in release X byt not in Y" yet.
> > Bugzilla has a field for "fix this bug by release X". I don't think the
> > Debian BTS has any such field either.
>
> Our internal SQL-based bug database lets you do it, indirectly. The
> bug state can only be OPENED, ASSIGNED, FIXED etc like GNATS, but there's
> also a field for the release containing the fix. Given something like
> this, it's not difficult to write an SQL query that shows all outstanding
> bugs on the 3.0 branch, as you would also include bugs marked FIXED
> if the fix release were set to 3.1. This would require, though, that
> the bug database be updated when a fix is back-ported.
A large proportion of bugs could be automatically verified, given machines
running the most common systems used for GCC with various GCC versions
installed. With any new system, perhaps we should try to arrange for
gccbug to support creating a bug report from which a testcase can be
automatically extracted (and support adding such test procedures to a bug
report afterwards), so information about affected versions could be
derived automatically.
--
Joseph S. Myers
jsm28@cam.ac.uk
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: in_avail() bug not fixed in 3.0.3
2001-12-14 11:45 ` Phil Edwards
@ 2001-12-14 12:05 ` Joe Buck
2001-12-14 12:05 ` Joseph S. Myers
0 siblings, 1 reply; 6+ messages in thread
From: Joe Buck @ 2001-12-14 12:05 UTC (permalink / raw)
To: Phil Edwards; +Cc: Joe Buck, Alexandre Oliva, David Rasmussen, gcc
I wrote:
> > but it does point out a problem: we
> > don't have a way of querying GNATS to find which bugs fall in this
> > category (fixed for 3.1 but not for 3.0.x).
Phil Edwards writes:
> This is YARTTOG[*]. I haven't seen any other bug-tracking system
> which offers this specific behavior ("fixed in release X byt not in Y" yet.
> Bugzilla has a field for "fix this bug by release X". I don't think the
> Debian BTS has any such field either.
Our internal SQL-based bug database lets you do it, indirectly. The
bug state can only be OPENED, ASSIGNED, FIXED etc like GNATS, but there's
also a field for the release containing the fix. Given something like
this, it's not difficult to write an SQL query that shows all outstanding
bugs on the 3.0 branch, as you would also include bugs marked FIXED
if the fix release were set to 3.1. This would require, though, that
the bug database be updated when a fix is back-ported.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2001-12-14 20:05 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-12-14 8:05 in_avail() bug not fixed in 3.0.3 David Rasmussen
2001-12-14 10:26 ` Alexandre Oliva
2001-12-14 11:32 ` Joe Buck
2001-12-14 11:45 ` Phil Edwards
2001-12-14 12:05 ` Joe Buck
2001-12-14 12:05 ` Joseph S. Myers
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).