[Bug libstdc++/40712] locale(const locale, const char*, locale::category) can create broken locale
--- 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 of __nl_langinfo_l(__MON_GROUPING, __cloc) into it as part of _M_initialize_moneypunct. Reasonable solution. Actually, I thougth that _M_initialize_moneypunct had already implemented in such way. As for we didn't notice the issue much earlier - it is strange, but in many other cases locale, created with this constructor, behaves correctly(at least, does not cause program to abort and remains internal properties). And this case crashes program not on every system. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40712
[Bug libstdc++/40712] New: locale(const locale, const char*, locale::category) can create broken locale
This code causes SIGFAULT on Ubuntu 8.10:
#include locale
using namespace std;
int main()
{
locale loc(locale(C), en_US, locale::monetary);
use_facetmoneypunctchar (loc).grouping();
return 0;
}
Tested both with native gcc and one builded from svn.
According to gdb, sigfault is caused by strlen while converting c-string to
c++-string when returns from moneypunctchar::do_grouping().
and...@andrew-desktop:~/work/test$ gcc --version
gcc (Ubuntu 4.3.2-1ubuntu12) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
and...@andrew-desktop:~/work/test$ /home/andrew/gcc/bin/gcc --version
gcc (GCC) 4.5.0 20090709 (experimental)
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
and...@andrew-desktop:~/work/test$ g++ test.cpp ./a.out
Segmentation fault
--
Summary: locale(const locale, const char*, locale::category) can
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
[Bug libstdc++/40606] Inside new_handler throw; operator may cause abort
--- 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 other OSes(even SLES10) and SLES11 on other architectures(even on x86_64). But problem have arisen only on SLES11[IA64]. -- tsyvarev at ispras dot ru changed: What|Removed |Added GCC target triplet||ia64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40606
[Bug target/40606] Inside new_handler throw; operator may cause abort
--- 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? or with exception unwind mechanism? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40606
[Bug libstdc++/40606] New: Inside new_handler throw; operator may cause abort
The attached example causes abort() on SLES11 (IA64). This example comes from a test suite that checks operator new in various situations. According to the execution results of these tests, it seems to me that the problem is somewhere in throw; operator inside NewHandlerBox::new_handler_box() method, which is called as new_handler when new operator fails to allocate memory. Unfortunately I have no direct access to the machine with this configuration (SLES11 installed on IA64 architecture), so I couldn't prepare a shorter example program. For now, I can't say which parts of the program are essential to reproduce the problem and which ones are not. However, in a very simple example the problem wasn't reproduced. Also, the mentioned test suite was executed on many other machines with different OSes and architectures, but the problem have not arisen there so far. -- Summary: Inside new_handler throw; operator may cause abort 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=40606
[Bug libstdc++/40606] Inside new_handler throw; operator may cause abort
--- 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, there is no reasonable backtrace, as the error is reported via abort() and the stack only shows the abort() call. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40606
[Bug libstdc++/40606] Inside new_handler throw; operator may cause abort
--- 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/bugzilla/show_bug.cgi?id=40606
[Bug libstdc++/40184] New: locale(const char* std_name) can create invalid facets for nonuniform locale
Constructor locale(const char* std_name), when called with name of nonuniform
locale (like LC_CTYPE=...;LC_COLLATE=...;...), can create locale with
incorrect content of some its facets: these facets differ from facets of
locale, created via locale(const locale other, const char* std_name, category)
with subsequent replacing of categories. While this locale has same name as
argument of locale(const char* std_name).
This behaviour contradicts description of member-function name() (22.1.1.3,
p5):
If *this has a name, then locale(name().c_str()) is equivalent to *this.
Example below demonstrates contradiction of this statement on curr_symbol()
property of moneypunctwchar_t facet:
#include locale
#include cassert
int main()
{
using namespace std;
locale loc(locale(C), en_GB.utf8, locale::monetary);
const moneypunctwchar_t mp =
use_facetmoneypunctwchar_t (loc);
locale loc_copy(loc.name().c_str());
const moneypunctwchar_t mp_copy =
use_facetmoneypunctwchar_t (loc_copy);
assert(mp.curr_symbol() == mp_copy.curr_symbol());
return 0;
}
It seems, the source of the problem is a method of filling properties of named
locale. E.g., for moneypunctwchar_t facet, the method performs the following:
1)sets the current POSIX locale with given name,
2)sets some properties of C++ locale, using __nl_langinfo_l() function call,
3)the rest properties of C++ locale are obtained from char-versions of them
using mbsrtowcs()-like functions.
But mbsrtowcs() use current LC_CTYPE category, which name may differ from the
name of LC_MONETARY category in nonuniform locale. So mbsrtowcs() assumes that
string, passed to it, belongs to one charset(according to LC_TYPE category
name), while it belongs to the another (according to LC_MONETARY category
name).
This fact entails wrong property value, obtained via such call to mbsrtowcs().
Up to garbage, because implementation doesn't verify result of mbsrtowcs(),
which doesn't set terminating '\0' in case of error.
The fact, that the implementation doest't verify result of mbsrtowcs(), also
seems strange - absence of terminating '\0' may lead to SIGFAULT.
--
Summary: locale(const char* std_name) can create invalid facets
for nonuniform 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=40184
[Bug libstdc++/40184] locale(const char* std_name) can create invalid facets for nonuniform locale
--- 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 result could be usefull, at least for terminate resulting string with '\0' if mbsrtowcs cannot convert input string for some reason. E.g., there is a system where mbsrtowcs() cannot convert every non-ASCII character, but all other locale features work correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40184
[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.
--- 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 is the same regardless of whether char is a signed or unsigned type. Arbitrary length is not quite correct here - 123,456 violates grouping, given with string(1, CHAR_MAX). Standard use term unlimited length, which means(as I understand) that all other digits should incorporate in only one group - only 123456 is correct. (In reply to comment #6) Actually, libstdc++ stores 123456, which is indeed fine, and sets failbit | eofbit, failbit exactly because of the issue discussed here. The thing is that, according to the standard, CHAR_MAX should be treats similar as -1. But implementation treats string(1, -1) as no grouping at all, and stops read, when has encountered symbol ','. So only 123 is accumulated. This behaviour seems correct for me (though standard treats only string() as no grouping at all, 22.2.2.1.2, p8). So with string(1, CHAR_MAX) only 123 should be accumulated, not 123,456. In other words, test is passed when CHAR_MAX is replaced with -1. Inside grouping string, CHAR_MAX means same as -1(according to the standard). So test should be passed with original text. The same is about the second test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.
--- 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 - only 123456 is correct. I don't read that anywhere in the Standard. Could you clarify this a bit? Do you mean that when reading 123,456 with string(1, -1), failbit shouldn't be set? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.
--- 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. Other separators shouldn't appear. Grouping string \003 doesn't fit for this purpose as it separates all 3-digits groups: 1,234,567. Before this PR, I thought that \003\177 is sufficient for this purpose. But, as I understand now, the representations like 12,34,567 are acceptable in this case, which is not what I would like to have. Could you suggest which grouping string should be used to do such number representation? Or is this unachievable? I investigated locale support in POSIX, such number representation is achieved there with \003\177. It seems strange for me that similar mechanism is not work with C++ locales. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.
--- 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 in that do no admit repetitions, thus saying explicitly that such group is effectively the last, arbitrarily long, one. Yes, I meen exactly this. Also, current implementation follows this strategy - accroding to the tests, and according to it's source code. So it is strange for me, that the standard for num_get::do_get() say, that only string() is indicator of no grouping at all. While string(1,-1) and string(1,CHAR_MAX) also force number representation to have only one group. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
[Bug libstdc++/39168] New: Incorrect interpritation of CHAR_MAX inside grouping string in monetary and numeric facets.
Description of numpunct::do_grouping() (22.2.3.1.2, p3): Returns: A basic_stringchar vec used as a vector of integer values, in which each element vec[i] represents the number of digits in the group at position i, starting with position 0 as the rightmost group. If vec.size() = i, the number is the same as group (i-1); if (i0 || vec[i]=0 || vec[i]==CHAR_MAX), the size of the digit group is unlimited. But num_put and num_get implementations don't interpret condition (vec[i]==CHAR_MAX) as condition of group with unlimited size, but interpret value CHAR_MAX as regular size of digits group. According to the code, condition (static_castsigned char(vec[i]) 0) is used as an indicator of regular group size. This means range 1..127 for vec[i] values. But on architectures with char ~ signed char(e.g. x86), CHAR_MAX is 127, so the range shouldn't include value 127. In tests, string(1, CHAR_MAX) is used as grouping string. Like string() and string(1, -1), this should disable grouping at all. But on architectures with char ~ signed char tests failed. On architectures with char ~ unsigned char or when CHAR_MAX replaced with -1, all became ok. -- Summary: Incorrect interpritation of CHAR_MAX inside grouping string in monetary and numeric 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=39168
[Bug libstdc++/39168] Incorrect interpritation of CHAR_MAX inside grouping string in monetary and numeric facets.
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
[Bug libstdc++/39168] Incorrect interpritation of CHAR_MAX inside grouping string in monetary and numeric facets.
--- 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 these digits as is, without thousands separator. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
[Bug libstdc++/38399] money_get read decimal point when frac_digits() = 0
--- 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
#include sstream
#include iostream
using namespace std;
class my_moneypunct : public moneypunctchar
{
protected:
//this should disable fraction part of monetary value
int do_frac_digits()const {return 0;}
};
int main()
{
locale loc(locale(), new my_moneypunct());
stringstream ss(123.455);
ss.imbue(loc);
string digits;
ios_base::iostate err;
istreambuf_iteratorchar iter =
use_facetmoney_getchar (loc).get(ss, 0, false, ss, err, digits);
string rest = string(iter, istreambuf_iteratorchar());
cout digits is \ digits \\n;
cout rest of stream is \ rest \\n;
return 0;
}
Output doesn't change.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38399
[Bug libstdc++/38411] [4.4 Regression] Revision 142439 caused 22_locale/locale/cons/7.cc execution test
--- 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 classic C numeric formats, i.e. they contain information equivalent to that contained in the C locale or their wide character counterparts as if obtained by a call to widen. also, 22.2.3.1.2 p.2 says: char_type do_thousands_sep() const; Returns: A character for use as the digit group separator. The required instantiations return , or L,. It appears, that according to C++ standard, thousands separator for C locale is ','. But according to the ISO standard of C(POSIX) locale (Section 7.3, Locale Definition), thousands separator in this locale should be '\0', which means N/A or not assigned. Or is this reasoning wrong? -- tsyvarev at ispras dot ru changed: What|Removed |Added CC||tsyvarev at ispras dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38411
[Bug libstdc++/38399] New: money_get read decimal point when frac_digits() = 0
From description of moneypunct facet(22.2.6.3, p3):
The format of the numeric monetary value is a decimal number:
value ::= units [ decimal-point [ digits ]] | decimal-point digits
if frac_digits() returns a positive value, or
value ::= units
otherwise.
But the implementation of money_get::do_get() reads from input stream decimal
point and digits after it and write them to the result(units or digits), even
when frac_digits() return nonpositive value.
In similar situation with grouping, when grouping string indicates that
grouping shouldn't not be applied, implementation stops read when it encounters
thousands separator.
Example:
#include locale
#include sstream
#include iostream
using namespace std;
class my_moneypunct : public moneypunctchar
{
protected:
//this should disable fraction part of monetary value
int do_frac_digits()const {return 0;}
};
int main()
{
locale loc(locale(), new my_moneypunct());
stringstream ss(123.456);
ss.imbue(loc);
string digits;
ios_base::iostate err;
use_facetmoney_getchar (loc).get(ss, 0, false, ss, err, digits);
string rest(istreambuf_iteratorchar(ss), istreambuf_iteratorchar());
cout digits is \ digits \\n;
cout rest of stream is \ rest \\n;
return 0;
}
[EMAIL PROTECTED] money_get_frac_digits]$ g++ ./test.cpp ./a.out
digits is 123456
rest of stream is
[EMAIL PROTECTED] money_get_frac_digits]$ g++ --version
g++ (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8)
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for 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
[Bug libstdc++/38368] locale(const char* std_name) may create locale with broken facets
--- 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). But this is seems not a bug - because in POSIX locale GROUPING is -1, grouping is not applied to numbers, so THOUSANDS_SEP shouldn't be used. Also __MON_THOUSANDS_SEP shouldn't be used (__MON_GROUPING is -1) and __MON_DECIMAL_POINT (__MON_FRAC_DIGITS is -1). C++ is dealing separately with C locale, so it may define some cases in its own way. But it should do this in self-consitent manner - the standard stays, that (from the description of name() method of locale, 22.1.1.3, p.5) If *this has a name, then locale(name().c_str()) is equivalent to *this. So, if for locale created via locale(C) numpunctchar::thousands_sep() returns ',' then for every locale with name C, even with only LC_NUMERIC=C numpunctchar::thousands_sep() should also return ',', not '\0'. The same for moneypunctchar::decimal_point() - because in locale(C) it returns ., it should return . in any other locale with LC_MONETARY=C. moneypunctchar::thousands_sep() return '\0' in locale(C) (intentionally or unintentionally, i don't know), so in other locale with LC_MONETARY=C it can return '\0', this isn't a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38368
[Bug libstdc++/38365] Locale, constructed from named and unnamed locales, become named
--- 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 (*this and __impl) have names, or when *this locale hasn't name. But when *this locale has name, but __imp hasn't, the function doesn't clear name of *this. Your patch fixes the problem at the level of the locale constructor, but why do not fix this problem at the level of _M_replace_categories() instead? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38365
[Bug libstdc++/38368] New: locale(const char* std_name) may create locale with broken facets
Locale constructor locale(const char* std_name) may create locale with broken
facets.
When std_name looks like CAT1=name1;...;CATN=nameN, categories for which name
is C may have members, which differ from ones in C locale.
e.g. decimal_point() in moneypunct facet returns '\0' while in C locale it
returns '.'.
Also thousands_sep() in numpunct returns '\0' while in C locale it returns
','.
Example:
[test.cpp]
#include locale
#include iostream
using namespace std;
int main()
{
locale loc(locale(C), en_US, locale::collate);
cout Name of locale is loc.name() endl;
locale loc_copy(loc.name().c_str());
if(use_facetmoneypunctchar (loc_copy).decimal_point() == '\0')
cout decimal_point() is '\\0'\n;
return 0;
}
[EMAIL PROTECTED] locale_create_from_name]$ g++ test.cpp ./a.out
Name of locale is
LC_CTYPE=C;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=en_US;LC_MONETARY=C;LC_MESSAGES=C;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C
decimal_point() is '\0'
[EMAIL PROTECTED] locale_create_from_name]$ g++ --version
g++ (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8)
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY 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
[Bug libstdc++/38365] New: Locale, constructed from named and unnamed locales, become named
Locale constructor
locale(const locale other, const locale one, locale::category cats)
creates named locale when 'other' - named locale, but 'one' - unnamed.
According to 22.1.1 p8:
A locale constructed from a name string (such as POSIX), or from parts of two
named locales, has a name; all others do not.
Example:
[test.cpp]
#include locale
#include iostream
using namespace std;
int main()
{
locale other(locale(C));
locale one(locale(en_US), new ctypechar());
locale loc(other, one, locale::collate);
cout one.name() is one.name() endl;
cout other.name() is other.name() endl;
cout loc.name() is loc.name() endl;
return 0;
}
[EMAIL PROTECTED] locale_name]$ g++ test.cpp ./a.out
one.name() is *
other.name() is C
loc.name() is C
[EMAIL PROTECTED] locale_name]$ g++ --version
g++ (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8)
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY 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
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
[Bug libstdc++/38210] New: num_put::do_put(void*) performs padding incorrectly when adjustfield==internal
The following num_put member function
iter_type do_put(iter_type out, ios_base str, char_type fill, const void* val)
const
incorrectly performs padding of a string to bring its length to the required
value if 'adjustfield' flag is equal to 'internal': instead of adding fill
characters after 0x it adds them at the beginning of the string
According to the description of padding options (22.2.2.2.2 p19), if
adjustfield == internal and representation after stage 1 began with 0x or 0X -
pad after x or X.
Example:
#include iostream
#include locale
using namespace std;
int main()
{
void *p = (void*)0x1;
cout.width(5);
cout internal p endl;
return 0;
}
output 0x1 while it should be 0x 1
--
Summary: num_put::do_put(void*) performs padding incorrectly
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
[Bug libstdc++/38196] New: num_put::do_put(bool) performs 'internal' padding incorrectly when boolalpha==true
The description of num_put::do_put(bool) function states (22.2.2.2.2): iter_type do_put(iter_type out, ios_base str, char_type fill, bool val) const; Effects: If (str.flags()ios_base::boolalpha)==0 then do out = do_put(out, str, fill, (int)val) Otherwise do const numpunct np = use_facetnumpunctcharT (loc); string_type s = val ? np.truename() : np.falsename(); and then insert the characters of s into out. It is not specified how exactly the insertion the characters of s into out iterator is performed. It seems that the padding of the string is done the same way as for the other functions from num_put::do_put() family, namely (22.2.2.2.2 p19 Table 61): adjustfield == iosbase::left - pad after adjustfield == iosbase::right - pad before adjustfield == internal and a sign occurs in the representation - pad after the sign adjustfield == internal and representation after stage 1 began with 0x or 0X - pad after x or X otherwise pad before num_put::do_put(bool), however, should output a string that in general is not a string representation of some number. It makes no sense for a string that can be arbitrary to process the sign symbols, 0x or 0X in a different way than its other substrings. That means, the 'internal' flag should be functionally equivalent to 'right' (pad before) in this case. This is exactly the way the operator for inserting sequences of symbols into a stream (operator for const charT*) is implemented. Although the description of padding in this case (27.6.2.5.4, p2) refers to the description of num_put::do_put, in practice the 'internal' flag is functionally equivalent to 'right' in this case, which makes sense. However, the implementation of num_put::do_put(bool) performs 'internal' padding not like operator for sequences of characters but rather the same way as the other functions from num_put::do_put family: it inserts fill symbols between the 'sign' or 0x/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: 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
[Bug libstdc++/38196] num_put::do_put(bool) performs 'internal' padding incorrectly when boolalpha==true
--- 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::classic(), new my_numpunct());
cout.imbue(my_loc);
cout.width(6);
bool b = false;
cout internal boolalpha b endl;
return 0;
}
output - no- instead of -no-
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38196
[Bug libstdc++/38081] time_get::do_get_weekday does not always recognize full names of weekdays
--- 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 PROTECTED]:/mnt/hgfs/shared/temp/test$ g++ test.cpp ./a.out t.tm_wday becomes 1, expected 1 t.tm_wday becomes -1, expected 1 t.tm_wday becomes 1, expected -1 In Russian locale every abbriviated name of month is always a prefix of full name, so conclusion about do_get_monthname() is done only according its code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38081
[Bug libstdc++/38081] New: time_get::do_get_weekday does not always recognize full names of weekdays
The description of time_get::do_get_weekday() and time_get::do_get_monthname() states (22.2.5.1.2): Effects: Reads characters starting at s until it has extracted the (perhaps abbreviated) name of a weekday or month. If it finds an abbreviation that is followed by characters that could match a full name, it continues reading until it matches the full name or fails. However, if the abbreviated name of a weekday is not a prefix of its full name, the full name is not recognized by the function. For example, the Russian name of Monday (Ponedelnik) is not recognized as Monday (locale - ru_RU.iso88595) because of this. But if one replaces the 1st 3 symbols of this word with the abbreviated Russian name of Monday (Pnd), the resulting string (Pndedelnik) is recognized as the full name of Monday, which is wrong. According to the source of time_get::do_get_weekday function's implementation as well as the comments in it, it is definitely assumed in the function that the abbreviated name of a weekday should be a prefix of its full name. A similar problem takes place for time_get::do_get_monthname() function. -- Summary: time_get::do_get_weekday does not always recognize full names of weekdays 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=38081
[Bug libstdc++/37957] Wrong behaviour of num_get::do_get(bool) in the case when one target sequence is a prefix of the other one
--- 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
[Bug libstdc++/37958] num_get::do_get(bool) sets eofbit flag incorrectly when boolalpha == true
--- 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 basic_istringstream one can count symbols, which implementation is really read. These symbols are those, for which (in == end) or/and (*in) was performed (++in operation does not affect on this counter). Test testsuite/22_locale/num_get/get/char/37958.cc may be extend as: - istringstream iss0, iss1, iss2, iss3; + basic_istringstream1char iss0, iss1, iss2, iss3; ... iss0.str(true); iss0.setf(ios_base::boolalpha); err = ios_base::goodbit; end = ng0.get(iss0.rdbuf(), 0, iss0, err, b0); VERIFY( err == ios_base::goodbit ); VERIFY( b0 == true ); + VERIFY( iss0.rdbuf()-chars_read() == 4);//after character 'e' (in == end) should not be performed iss0.str(false); iss0.clear(); err = ios_base::goodbit; end = ng0.get(iss0.rdbuf(), 0, iss0, err, b0); VERIFY( err == ios_base::goodbit ); VERIFY( b0 == false ); + VERIFY( iss0.rdbuf()-chars_read() == 5); ... iss2.str(1); iss2.setf(ios_base::boolalpha); err = ios_base::goodbit; end = ng2.get(iss2.rdbuf(), 0, iss2, err, b2); VERIFY( err == ios_base::goodbit ); VERIFY( b2 == true ); + VERIFY( iss2.rdbuf()-chars_read() == 1); ... iss3.str(); iss3.clear(); b3 = true; err = ios_base::goodbit; end = ng3.get(iss3.rdbuf(), 0, iss3, err, b3); VERIFY( err == ios_base::failbit ); VERIFY( b3 == false ); + VERIFY( iss3.rdbuf()-chars_read() == 0);//stream should not be readed at all -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
[Bug libstdc++/37958] num_get::do_get(bool) sets eofbit flag incorrectly when boolalpha == true
--- 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 a match(22.2.2.1.2, p15): Successive characters in the range [in,end) (see 23.1.1) are obtained and matched against corresponding positions in the target sequences ONLY as necessary to identify a unique match. The input iterator in is compared to end ONLY when necessary to obtain a character. If also take into account constraints on setting eofbit flag: if, when seeking another character to match, it is found that (in == end) and if the reason for the failure was that (in == end)., one may conclude, that eofbit flag should be set IF and ONLY IF comparision (in == end) was performed and it returned true. Declaration bool __testeof = __beg == __end; in the patched code means, that implementation always compares (in == end) at start, even when input and target sequences are empty (). In that case, err will be set to failbit, which conforms to the example in the standard: For empty targets (), any input sequence yields err == str.failbit But input sequence should not be read at all in this case, so comparision (in == end) should not be performed! There are also other cases, when implementation performs unnecessary comparision (in == end). -- tsyvarev at ispras dot ru changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
[Bug libstdc++/37958] num_get::do_get(bool) sets eofbit flag incorrectly when boolalpha == true
--- 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 == end). For example, for target sequences false and true and input sequence false eofbit flag won't be set in err, but when __beg points to 'e', (++__beg == __end) in the last if-operator inside for-cycle will return true. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
[Bug libstdc++/37958] num_get::do_get(bool) sets eofbit flag incorrectly when boolalpha == true
--- 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 verify, whether do_get() implementation performs unnesessary call of (in == end). First test in main() verify situation, when all sequences are empty. Second and third - falsename is false, truename is true, input sequence is false or true correspondingly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
[Bug libstdc++/37958] num_get::do_get(bool) sets eofbit flag incorrectly when boolalpha == true
--- 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 not correct... If run test in the second attachment, in the second testcase(falsename - false, truename - true, input - false) eofbit flag won't be set(it is right). But in the third testcase(input is true) implementation set eofbit flag. Problem is that __lim cannot be used as stopper for the cycle, because target sequences have different lenght. If move last if in for-cycle if ((!__testt __n = __lc-_M_falsename_size) || (!__testf __n = __lc-_M_truename_size)) break; to the beginning of the cycle, all seems to be correct... except case of identical target sequences. Later I'll try to write more presize test, and may try to write patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
[Bug libstdc++/37958] num_get::do_get(bool) sets eofbit flag incorrectly when boolalpha == true
--- 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* set it, in that case, because val is
set
only when a target sequence is uniquely matched, thus we don't look beyond the
last matched character.
I suppose there is a situations when eofbit is set:
Assume, sequence is fals. Because fals is prefix of false, do_get()
should try to obtained character after 's', but it found, that (in==end). So it
should set err to (failbit | eofbit).
Here is an example of a situation when this difference between standard and
current implementation may be significant.
Consider the stream, in which operation (in == end) will block process until a
character is available. So, comparision (in == end) always returns false, until
stream is forced to close.
For example, assume the stream is connected to terminal. So if the stream is
depleted but the program performs the comparison (in == end), current process
will be blocked until the user inputs another character.
For the prompt Are you sure to perform this operation? it is sufficient for
the user to input {'y', 'e', 's'} and program will interpret this as
affirmative answer.
But for current implementation user should input {'y', 'e', 's', enter},
because after reading yes do_get() performs the comparison (in == end) to
verify whether eofbit should be set in err. But this call will block program
until the user inputs another character, which does not affect the
interpretation of the user's answer, though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
[Bug libstdc++/37958] num_get::do_get(bool) sets eofbit flag incorrectly when boolalpha == true
--- 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 == true and err == str.goodbit) Output the same: [EMAIL PROTECTED]:/mnt/hgfs/shared/temp/test$ g++ test.cpp ./a.out eofbit was set. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
[Bug libstdc++/37957] Wrong behaviour of num_get::do_get(bool) in the case when one target sequence is a prefix of the other one
--- 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
[Bug libstdc++/37957] New: Wrong behaviour of num_get::do_get(bool) in the case when one target sequence is a prefix of the other one
There are some examples in the description of member function of the num_get facet iter_type do_get(iter_type in, iter_type end, ios_base str, ios_base::iostate err, bool val) const for the case when (str.flags() ios_base::boolalpha) != 0, that clarify the algorithm that the function implements (22.2.2.1.2, p16): For targets true: a and false: abb, the input sequence a yields val == true and err == str.eofbit; the input sequence abc yields err = str.failbit, with in ending at the 'c'. In the last example, however, the attached test program shows the following: [EMAIL PROTECTED]:/mnt/hgfs/shared/temp/test$ g++ test.cpp ./a.out failbit wasn't set, and result is true Rest of stream is 'bc'. It seems (from this and other tests), that the implementation stops reading from 'in' when it founds a sequence that matches one of the target sequences. But it should test, whether the sequence is a (proper) prefix of another target sequence. And if it is, the function should continue reading. This behaviour doesn't follow obviously from the description of the function, but it follows from the examples. The detailed bug description can be found at: http://linuxtesting.org/results/report?num=S0736 -- Summary: Wrong behaviour of num_get::do_get(bool) in the case when one target sequence is a prefix of the other 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
[Bug libstdc++/37958] New: num_get::do_get(bool) sets eofbit flag incorrectly when boolalpha == true
There are some examples in the description of member function of the num_get
facet
iter_type do_get(iter_type in, iter_type end, ios_base str, ios_base::iostate
err, bool val) const
for the case when (str.flags() ios_base::boolalpha) != 0, that clarify the
algorithm that the function implements (22.2.2.1.2, p16):
For targets true: 1 and false: 0, the input sequence 1 yields val == true
and err == str.goodbit. For empty targets (), any input sequence yields err
==
str.failbit.
But in both cases implementation also sets flag str.eofbit in err.
It seems that implementation always set str.eofbit when after call of the
function (in == end).
But standard states(22.2.2.1.2, p16) that this flag should be set only when:
if, when seeking another character to match, it is found that (in == end) (on
success)
or if the reason for the failure was that (in == end) (on fail)
This conditions are not the same as simply (in == end).
Short test reproduce this difference for targets true and false and input
sequence true (similar to the first example):
test.cpp:
#include iostream
#include sstream
using namespace std;
int main()
{
istringstream is(true);
bool result;
is boolalpha result;
if(is.rdstate() ios_base::eofbit)
cout eofbit was set. endl;
else
cout eofbit wasn't set. endl;
return 0;
}
[EMAIL PROTECTED]:/mnt/hgfs/shared/temp/test$ g++ test.cpp ./a.out
eofbit was set.
[EMAIL PROTECTED]:/mnt/hgfs/shared/temp/test$ g++ --version
g++ (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
The detailed bug description can be found at:
http://linuxtesting.org/results/report?num=S0735
--
Summary: num_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
[Bug libstdc++/37475] New: codecvt::do_in/do_out functions return ok when the output sequence has zero length
The following member functions of the class codecvtwchar_t, char, mbstate_t result in(stateT state, const externT* from, const externT* from_end, const externT* from_next, internT* to, internT* to_limit, internT* to_next) const and result out(stateT state, const internT* from, const internT* from_end, const internT* from_next, externT* to, externT* to_limit, externT* to_next) const return ok if (to==to_limit) but (from from_end), that is, when the output sequence contains no elements but the input sequence is not empty. However, as appears from the description of the functions' return values (22.2.1.5.2 p4), partial should be returned instead: ok - completed the conversion partial - not all source characters converted error - encountered a character in [from,from_end) that it could not convert noconv - internT and externT are the same type, and input sequence is identical to converted sequence Note that these functions do return partial if the output sequence is not empty but still not large enough to contain all converted characters from the input sequence, that is, if 0 (to_limit - to) (from_end - from). [EMAIL PROTECTED]:/mnt/hgfs/shared/temp/test$ g++ -Wall test.cpp ./a.out Calls do_out() function when size of input sequenceis 2, output - 1: do_out() returns partial. Calls do_out() function when size of input sequenceis 2, output - 0: do_out() returns ok. Calls do_in() function when size of input sequenceis 2, output - 1: do_in() returns partial. Calls do_in() function when size of input sequenceis 2, output - 0: do_in() returns ok. [EMAIL PROTECTED]:/mnt/hgfs/shared/temp/test$ g++ --version g++ (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Summary: codecvt::do_in/do_out functions return ok when the output sequence has zero length 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
[Bug libstdc++/37475] codecvt::do_in/do_out functions return ok when the output sequence has zero length
--- 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
[Bug libstdc++/37477] New: std::uncaught_exception() returns wrong value after entering terminate() in some cases
The description of uncaught_exception() throw() function states (18.6.4): Returns: true after completing evaluation of a throw-expression until either completing initialization of the exception-declaration in the matching handler or entering unexpected() due to the throw; or after entering terminate() for any reason other than an explicit call to terminate(). Apart from an explicit call to terminate() from the user's code, terminate() is called in the following situations (15.5.1): 1. When the exception handling mechanism, after completing evaluation of the expression to be thrown but before the exception is caught, calls a user function that exits via an uncaught exception. 2. When the exception handling mechanism cannot find a handler for a thrown exception. 3. When the destruction of an object during stack unwinding exits using an exception. 4. When construction or destruction of a non-local object with static storage duration exits using an exception. 5. When execution of a function registered with atexit exits using an exception. 6. When a throw-expression with no operand attempts to rethrow an exception and no exception is being handled. 7. When unexpected throws an exception which is not allowed by the previously violated exception specification, and std::bad_exception is not included in that exception-specification. However std::uncaught_exception called within a terminate_handler returns false in the cases 2,4,5,7 and true in the other cases (terminate_handler is specified using std::set_terminate()). The attached examples demonstrate the above 7 situations when terminate() is called implicitly and display the return value of std::uncaught_exception(). For example, reproducing situation 2: [EMAIL PROTECTED]:/mnt/hgfs/shared/temp/test$ g++ -Wall test2.cpp ./a.out Exception will be thrown and it won't be catched. This situation meets the following condition when terminate should be called: 2.When the exception handling mechanism cannot find a handler for a thrown exception. Inside terminate_handler uncaught_exception() returns *false*. terminate called after throwing an instance of 'char const*' Aborted (core dumped) [EMAIL PROTECTED]:/mnt/hgfs/shared/temp/test$ g++ --version g++ (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Summary: std::uncaught_exception() returns wrong value after entering terminate() in some cases 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=37477
[Bug libstdc++/37477] std::uncaught_exception() returns wrong value after entering terminate() in some cases
--- 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?id=37477
