--- Comment #3 from tsyvarev at ispras dot ru 2009-07-13 11:55 ---
(In reply to comment #2)
I think this constructor never ever worked correctly. The only solution I can
see at the moment is consistently dynamically allocating _M_data-_M_grouping,
and copying the characters
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tsyvarev at ispras dot ru
http://gcc.gnu.org/bugzilla
--- Comment #7 from tsyvarev at ispras dot ru 2009-07-02 06:16 ---
gcc --version gets:
gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291]
Yes, problem very probably target dependent - as I said, test suite was
executed on many other machines, including IA64 arhictecures
--- Comment #11 from tsyvarev at ispras dot ru 2009-07-02 11:26 ---
Ok, sorry for noise. I'll try with libunwind.
Only thing - what does it mean
invalid testcase because you make libunwind fail by setrlimit.
Does it mean that setrlimit shouldn't be used with new operator
at ispras dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40606
--- Comment #2 from tsyvarev at ispras dot ru 2009-07-01 13:54 ---
Created an attachment (id=18108)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18108action=view)
reproduce problem
g++ -O2 test.cpp ./a.out
Executing test_4_10()
Aborted
Exit code is 134.
Unfortunately
--- Comment #5 from tsyvarev at ispras dot ru 2009-07-01 14:56 ---
Sorry, forgot about gcc version. I will post it not long after.
As for core C++ or libstdcxx problem - I don't know because couldn't localize
problem yet. Probably, this core C++ issue.
--
http://gcc.gnu.org
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tsyvarev at ispras dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40184
--- Comment #2 from tsyvarev at ispras dot ru 2009-05-18 14:37 ---
Yes, this seems reasonably. I also thought about smth. similar to this. Only it
is need to take into account using mbsrtowcs for other locale properties(if
they exist in others categories).
Anyway, checking of mbsrtowcs
--- Comment #7 from tsyvarev at ispras dot ru 2009-02-13 11:21 ---
(In reply to comment #4)
I'm not sure I understand your rationale or I agree that this is a bug. IIUC,
string(1, CHAR_MAX) indicates that groups may be of arbitrary length, which
includes 123,456 This behavior
--- Comment #10 from tsyvarev at ispras dot ru 2009-02-13 13:41 ---
(In reply to comment #8)
(In reply to comment #7)
Standard use term unlimited length, which
means(as I understand) that all other digits should incorporate in only one
group
--- Comment #12 from tsyvarev at ispras dot ru 2009-02-13 15:04 ---
Let's consider the following situation (seems lifelike to me). Suppose one
needs a representation of numbers in which only the last 3 digits are separated
from all other digits (grouped), like 1234,567 or 1234567,890
--- Comment #15 from tsyvarev at ispras dot ru 2009-02-13 15:38 ---
(In reply to comment #14)
If I understand correctly, in order to implement the POSIX behavior for C++,
assuming we want it, the Standard should be clarified to explain that values
=
0 or CHAR_MAX are different
gnu dot org
ReportedBy: tsyvarev at ispras dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
--- Comment #1 from tsyvarev at ispras dot ru 2009-02-12 15:30 ---
Created an attachment (id=17289)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17289action=view)
test for num_get::get() method
When grouping is disabled, thousands separator should not be read by get()
methods
--- Comment #2 from tsyvarev at ispras dot ru 2009-02-12 15:33 ---
Created an attachment (id=17290)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17290action=view)
test for money_put::put method
When grouping is disabled, money_put::put() method for digits should write
--- Comment #3 from tsyvarev at ispras dot ru 2008-12-05 09:53 ---
Thanks for remark. It seemed for me, that iterator returned by get() and
iterator constructed from stream directly are interchangeable. Now I see that
it isn't so.
Then, example should be rewritten:
#include locale
--- Comment #19 from tsyvarev at ispras dot ru 2008-12-05 11:08 ---
It seems that C++ standard contains contradiction about thousands separator in
C locale:
22.2.3.1, p1 says:
The instantiations required in Table 51 (22.1.1.1.1), namely numpunctwchar_t
and numpunctchar, provide
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tsyvarev at ispras dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38399
--- Comment #3 from tsyvarev at ispras dot ru 2008-12-03 16:27 ---
Yes, I see, this is feature of glibc: for POSIX locale it defines
THOUSANDS_SEP, __MON_THOUSANDS_SEP and __MON_DECIMAL_POINT as .
According to documentation for C-locale, this value means N/A (not assigned
--- Comment #4 from tsyvarev at ispras dot ru 2008-12-02 13:04 ---
According to the code, locale constructor calls
void locale::_Impl::_M_replace_categories(const _Impl* __imp, category __cat)
which already processes names of locales. This function works correctly, when
both locales
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tsyvarev at ispras dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38368
: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tsyvarev at ispras dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38365
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tsyvarev at ispras dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38210
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tsyvarev at ispras dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38196
--- Comment #1 from tsyvarev at ispras dot ru 2008-11-20 10:57 ---
Example:
#include iostream
#include locale
using namespace std;
class my_numpunct : public numpunctchar
{
protected:
string do_falsename() const {return -no-;}
};
int main()
{
locale my_loc = locale(locale
--- Comment #1 from tsyvarev at ispras dot ru 2008-11-11 13:41 ---
Created an attachment (id=16652)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16652action=view)
Reproduce bug with recognition of name of weekday
This test require locale ru_RU.iso88595 is installed.
[EMAIL
at ispras dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38081
--- Comment #2 from tsyvarev at ispras dot ru 2008-11-11 10:22 ---
This bug was fixed with fixing of bug 37958.
Testcase for bug 37958 also covers this one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37957
--- Comment #19 from tsyvarev at ispras dot ru 2008-11-06 07:16 ---
Created an attachment (id=16627)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16627action=view)
Analogue of basic_istringstream with (in == end) catching
Using basic_istringstream1 class instead
--- Comment #9 from tsyvarev at ispras dot ru 2008-11-01 12:21 ---
Patch seems doesn't resolve problem entirely.
The thing is that, besides of constraints on setting eofbit flag, the standard
claims, that comparision (in == end) should be perfomed only when it is needed
for identify
--- Comment #11 from tsyvarev at ispras dot ru 2008-11-01 15:52 ---
It is not nitpicking. Case with empty sequences is only demonstration, that
code behaviour is not confirm to the standard.
Really, it seems that in every succesfull matching it will be unnecessary
comparision
--- Comment #12 from tsyvarev at ispras dot ru 2008-11-01 16:01 ---
Created an attachment (id=16607)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16607action=view)
Test, whether there is an unnecessary comparision (in == end)
By hooking underflow() method of stringbuf, one can
--- Comment #15 from tsyvarev at ispras dot ru 2008-11-01 18:43 ---
I belived that the easier describe situation is the better.
Because setting flag is simpler to observe, than the fact of comparision (in ==
end), PR was reported about flag but comparision.
But the second patch is also
--- Comment #6 from tsyvarev at ispras dot ru 2008-10-31 10:48 ---
(In reply to comment #2)
Maybe now I see, what's behind your report: you believe that, when val is set,
eofbit should be set only when seeking another character to match. But that
would essentially boil down to *never
--- Comment #4 from tsyvarev at ispras dot ru 2008-10-31 10:34 ---
Created an attachment (id=16595)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16595action=view)
Test, modelling example from standard exactly
(For targets true: 1 and false: 0, the input sequence 1 yields val
--- Comment #1 from tsyvarev at ispras dot ru 2008-10-30 14:22 ---
Created an attachment (id=16589)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16589action=view)
reproduce bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37957
: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tsyvarev at ispras dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37957
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tsyvarev at ispras dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tsyvarev at ispras dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475
--- Comment #1 from tsyvarev at ispras dot ru 2008-09-11 09:35 ---
Created an attachment (id=16291)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16291action=view)
test.cpp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tsyvarev at ispras dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37477
--- Comment #1 from tsyvarev at ispras dot ru 2008-09-11 10:18 ---
Created an attachment (id=16292)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16292action=view)
test.tar
Reproduce situations when terminate is called implicitly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
43 matches
Mail list logo
