--- 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 c
create broken locale
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/show_bug.cgi?id=40712
--- 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 oper
--- 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 with
--- 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://g
--- 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=18108&action=view)
reproduce problem
g++ -O2 test.cpp && ./a.out
Executing test_4_10()
Aborted
Exit code is 134.
dot gnu dot org
ReportedBy: tsyvarev at ispras dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40606
--- 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
ity: 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=40184
--- 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_MA
--- 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"
--- 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 i
--- 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 "
--- 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=17290&action=view)
test for money_put<>::put method
When grouping is disabled, money_put<>::put() method for digits
--- 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=17289&action=view)
test for num_get<>::get() method
When grouping is disabled, thousands separator should not be read by
nassigned at gcc dot gnu dot org
ReportedBy: tsyvarev at ispras dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
--- 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 numpunct
and numpunct, provide
--- 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
#in
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--
Summary: money_get<> read decimal point when frac_digits() <= 0
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/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
BILITY or FITNESS FOR A PARTICULAR PURPOSE.
--
Summary: locale(const char* std_name) may create locale with
broken facets
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/show_bug.cgi?id=38368
TY or FITNESS FOR A PARTICULAR PURPOSE.
--
Summary: Locale, constructed from named and unnamed locales,
become named
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
when adjustfield==internal
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/show_bug.cgi?id=38210
--- Comment #1 from tsyvarev at ispras dot ru 2008-11-20 10:57 ---
Example:
#include
#include
using namespace std;
class my_numpunct : public numpunct
{
protected:
string do_falsename() const {return "-no-";}
};
int main()
{
locale my_loc = locale(locale::clas
"0X" and the rest of the string.
--
Summary: num_put<>::do_put(bool) performs 'internal' padding
incorrectly when boolalpha==true
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
--- 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=16652&action=view)
Reproduce bug with recognition of name of weekday
This test require locale "ru_RU.iso88595" is i
dot gnu dot org
ReportedBy: tsyvarev 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=16627&action=view)
Analogue of basic_istringstream with (in == end) catching
Using basic_istringstream1 class
--- 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 #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=16607&action=view)
Test, whether there is an unnecessary comparision (in == end)
By hooking underflow() method of stringbuf,
--- 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 (in
--- 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 ident
--- 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 essentiall
--- 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=16595&action=view)
Test, modelling example from standard exactly
("For targets true: "1" and false: "0"
_get<>::do_get(bool) sets eofbit flag incorrectly
when boolalpha == true
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/show_bug.cgi?id=37958
r one
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/show_bug.cgi?id=37957
--- 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=16589&action=view)
reproduce bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37957
--- 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=16292&action=view)
test.tar
Reproduce situations when terminate is called implicitly.
--
http://gcc.gnu.org/bugzilla/show_
nknown
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=37477
--- 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=16291&action=view)
test.cpp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475
th
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/show_bug.cgi?id=37475
43 matches
Mail list logo
