stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject issues against trunk, take 2 (was: Re: [jira] Closed: (STDCXX-515) std::basic_streambuf<>::xsputn() writes characters at the end, but not at the current position if reallocation of internal buffer occurs)
Date Tue, 28 Aug 2007 19:12:20 GMT
FYI: Unless we know for sure that we won't fix an issue in 4.2
the Affect Version/s shouldn't be 4.2 because 4.2 hasn't been
released yet.

We need to be able to track as accurately as we can which releases
were affected by each bug. It would also be helpful (for our own
internal purposes) to track regressions both introduced and fixed
during the same development cycle.

Suppose I am a user who wants to know which bugs have been reported
against the latest release I'm about to download, say 4.2, after it
comes out sometime in October. What do I search for? All bugs whose
Affect/s Versions contains 4.2. Here's what I get back from Jira:

What's my likely conclusion? That there are 19 bugs in the release.
I see that some of the have already been fixed but I need to look
at the Status field to see that *and* I also need to know to look
at the Fix Version/s field to see that they were fixed in the same
version. I then need to make the leap of figuring out that since
the Affects Version/s and Fix Version/s are the same, bugs for
which (Status==Resolved OR Status==Closed) AND Fix Versions IS
SUBSET OF Affect Versions holds don't really affect the tarball
I'm about to use.

As we briefly discussed a couple of weeks ago:
we can either use "trunk" for the Version fields to avoid giving
users the impression that the releases are of worse quality than
they really are, or we can invent some other labeling scheme. I
don't think "trunk" is ideal because, as Andrew notes, it doesn't
make it immediately obvious which development cycle the regression
corresponds to. In addition, if the regression doesn't get fixed
in the same dev cycle, the Affected Version/s will need to be
reassigned to to the released version that contained the bug.
I'm not sure that's avoidable though.

So, does anyone have any better idea than using "trunk" for bugs
that do not affect any released versions?


Farid Zaripov (JIRA) wrote:
>      [
> Farid Zaripov closed STDCXX-515.
> --------------------------------
> The regression test added:
>> std::basic_streambuf<>::xsputn() writes characters at the end, but not at the
current position if reallocation of internal buffer occurs
>> ----------------------------------------------------------------------------------------------------------------------------------------
>>                 Key: STDCXX-515
>>                 URL:
>>             Project: C++ Standard Library
>>          Issue Type: Bug
>>          Components: 27. Input/Output
>>    Affects Versions: 4.2
>>         Environment: All
>>            Reporter: Farid Zaripov
>>            Assignee: Farid Zaripov
>>             Fix For: 4.2
>> The test below asserts on i == 512.
>> test.cpp:
>> ------------------
>> #include <sstream>
>> #include <string>
>> #include <cassert>
>> int main ()
>> {
>>     for (size_t i = 1; i <= 1024; ++i) {
>>         std::stringstream strm;
>>         std::string s (i, 'a');
>>         strm << s;
>>         strm.seekp (-1, std::ios::cur);
>>         s.erase (0, 1);
>>         strm << "bc";
>>         s.append ("bc");
>>         assert (strm.str () == s);
>>     }
>>     return 0;
>> }
>> ------------------
>> The test output:
>> ------------------
>> test: test.cpp:15: int main (): Assertion `strm.str () == s' failed.
>> Aborted
>> ------------------

View raw message