[jira] Assigned: (STDCXX-701) update site to reflect graduation
[ https://issues.apache.org/jira/browse/STDCXX-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor reassigned STDCXX-701: --- Assignee: Martin Sebor update site to reflect graduation - Key: STDCXX-701 URL: https://issues.apache.org/jira/browse/STDCXX-701 Project: C++ Standard Library Issue Type: Task Components: Web Reporter: Martin Sebor Assignee: Martin Sebor Priority: Critical The stdcxx site needs to be updated to reflect our change of status to TLP after graduation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-701) update site to reflect graduation
update site to reflect graduation - Key: STDCXX-701 URL: https://issues.apache.org/jira/browse/STDCXX-701 Project: C++ Standard Library Issue Type: Task Components: Web Reporter: Martin Sebor Priority: Critical The stdcxx site needs to be updated to reflect our change of status to TLP after graduation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-360) [XLC++ 7.0] ICE compiling 2.smartptr.shared.cpp
[ https://issues.apache.org/jira/browse/STDCXX-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559636#action_12559636 ] Martin Sebor commented on STDCXX-360: - I say we close this as Cannot Reproduce. [XLC++ 7.0] ICE compiling 2.smartptr.shared.cpp --- Key: STDCXX-360 URL: https://issues.apache.org/jira/browse/STDCXX-360 Project: C++ Standard Library Issue Type: Bug Components: Tests Affects Versions: 4.1.3, 4.2.0 Environment: IBM XL C/C++ Version: 07.00..0009 Reporter: Martin Sebor Assignee: Travis Vitek Fix For: 4.2.1 Attachments: t.cpp.gz, t.cpp.gz.base64 PMR 02337,K78,000 The attached translation unit (gzipped and encoded in base-64) produced by preprocessing tests/tr1.util/2.smartptr.shared.cpp) causes an internal compiler error: $ xlC -qversion xlC -q64 -c -g t.cpp IBM XL C/C++ Enterprise Edition V7.0 Version: 07.00..0009 /nfs/packages/mdx/aix/compilers/5.3.0/va70_20070227/root/usr/vacpp/bin/.orig/xlC: 1501-230 Internal compiler error; please contact your Service Representative xlCcore_r -c -I/amd/devco/sebor/stdcxx-4.1.3/include/ansi -D_RWSTDDEBUG -D_RWSTD_USE_CONFIG -I/build/sebor/stdcxx-4.1.3-vacpp-7.0-15D/include -I/amd/devco/sebor/stdcxx-4.1.3/include -I/amd/devco/sebor/stdcxx-4.1.3/../rwtest -I/amd/devco/sebor/stdcxx-4.1.3/../rwtest/include -I/amd/devco/sebor/stdcxx-4.1.3/tests/include -g -q64 -qtemplateregistry=2.smartptr.shared.ti /amd/devco/sebor/stdcxx-4.1.3/tests/tr1.util/2.smartptr.shared.cpp /nfs/packages/mdx/aix/compilers/5.3.0/va70_20070227/root/usr/vacpp/bin/.orig/xlCcore_r: 1501-230 Internal compiler error; please contact your Service Representative -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-499) std::num_put inserts NUL thousand separator
[
https://issues.apache.org/jira/browse/STDCXX-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559638#action_12559638
]
Martin Sebor commented on STDCXX-499:
-
I'm tempted to close this as Won't Fix since it looks like a rare bug in the
locale definition file. On recent Linux systems there's just one locale that
suffers from this problem: bg_BG. I couldn't find any such locales on HP-UX. We
might want to look to see how many others besides fr_FR.ISO8859-1 there are on
Tru64, and check other platforms to see if it's more pervasive than just one or
two locales.
For future reference, here's an inefficient shell scrip I used to find other
such locales:
for l in `locale -a`; do LC_NUMERIC=$l locale -ck LC_NUMERIC | grep
thousands_sep=\\ /dev/null; if [ $? -eq 0 ]; then L=$L $l; fi; done
for l in $L; do grp=`LC_NUMERIC=$l locale -ck LC_NUMERIC | grep grouping`; echo
$l : $grp; done
std::num_put inserts NUL thousand separator
---
Key: STDCXX-499
URL: https://issues.apache.org/jira/browse/STDCXX-499
Project: C++ Standard Library
Issue Type: Bug
Components: 22. Localization
Affects Versions: 4.1.2, 4.1.3, 4.1.4
Reporter: Martin Sebor
Assignee: Martin Sebor
Fix For: 4.2.1
Moved from Rogue Wave Bugzilla:
http://bugzilla.cvo.roguewave.com/show_bug.cgi?id=1913
Original Message
Subject: num_put and null-character thousand separator
Date: Tue, 11 Jan 2005 16:10:23 -0500
From: Boris Gubenko [EMAIL PROTECTED]
Reply-To: Boris Gubenko [EMAIL PROTECTED]
Organization: Hewlett-Packard Co.
To: Martin Sebor [EMAIL PROTECTED]
Another locale-related issue that we fixed in rw stdlib v3.0 (and in
v2.0 also) is making sure, that num_put does not insert null thousand
separator character into the stream. Here is the fix in _num_put.cc
in v3.0 :
template class _CharT, class _OutputIter /* = ostreambuf_iterator_CharT
*/
_TYPENAME num_put_CharT, _OutputIter::iter_type
num_put_CharT, _OutputIter::
_C_put (iter_type __it, ios_base __flags, char_type __fill, int __type,
const void *__pval) const
{
const numpunctchar_type __np =
_V3_USE_FACET (numpunctchar_type, __flags.getloc ());
// FIXME: adjust buffer dynamically as necessary
char __buf [_RWSTD_DBL_MAX_10_EXP];
char *__pbuf = __buf;
const string __grouping = __np.grouping ();
const char *__grp = __grouping.c_str ();
const int __prec= __flags.precision ();
#if defined(__VMS) defined(__DECCXX) !defined(__DECFIXCXXL1730)
const char __nogrouping = _RWSTD_CHAR_MAX;
if (!__np.thousands_sep())
__grp = __nogrouping;
#endif
Here is the test:
cosf.zko.dec.com setenv LANG fr_FR.ISO8859-1
cosf.zko.dec.com locale -k thousands_sep
thousands_sep=
cosf.zko.dec.com cxx x.cxx a.out
null character thousand_sep was not inserted
cosf.zko.dec.com cxx x.cxx -D_RWSTD_USE_CONFIG -D_RWSTDDEBUG \
-I/usr/cxx1/boris/CXXL_1886-2/stdlib-4.0/stdlib/include/ \
-nocxxstd -L/usr/cxx1/boris/CXXL_1886-2/result/lib -lstd11s \
a.out
null character thousand_sep was inserted
cosf.zko.dec.com
x.cxx
-
#ifndef __USE_STD_IOSTREAM
#define __USE_STD_IOSTREAM
#endif
#include iostream
#include sstream
#include string
#include locale
#include locale.h
#ifdef __linux
#define FRENCH_LOCALE fr_FR
#else
#define FRENCH_LOCALE fr_FR.ISO8859-1
#endif
using namespace std;
int main()
{
ostringstream os;
if (setlocale(LC_ALL,FRENCH_LOCALE))
{
setlocale(LC_ALL,C);
os.imbue(locale(FRENCH_LOCALE));
os (double) 1.1 endl;
if ( (os.str())[2] == '\0' )
cout null character thousand_sep was inserted endl;
else
cout null character thousand_sep was not inserted endl;
}
return 0;
}
--- Additional Comments From [EMAIL PROTECTED] 2005-01-11 14:50:44
Original Message
Subject: Re: num_put and null-character thousand separator
Date: Tue, 11 Jan 2005 15:50:06 -0700
From: Martin Sebor [EMAIL PROTECTED]
To: Boris Gubenko [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
Boris Gubenko wrote:
Another locale-related issue that we fixed in rw stdlib v3.0 (and in
v2.0 also) is making sure, that num_put does not insert null thousand
separator character into the stream. Here is the fix in _num_put.cc
in v3.0 :
I don't think this fix would be quite correct in general. NUL is
a valid character that the locale library was specifically designed
to be able to insert and extract just like any other. In addition,
in the code below, operator==() need not be defined for the character
type.
...
Here is the test:
Thanks for the helpful test case.
My feeling is that this case points out a fundamental design
disconnect between
[jira] Updated: (STDCXX-636) 23.deque.special test fails assertions
[ https://issues.apache.org/jira/browse/STDCXX-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-636: Summary: 23.deque.special test fails assertions (was: 23.deque.special test fails) 23.deque.special test fails assertions -- Key: STDCXX-636 URL: https://issues.apache.org/jira/browse/STDCXX-636 Project: C++ Standard Library Issue Type: Bug Components: Tests Affects Versions: 4.2.0 Environment: All Reporter: Farid Zaripov Priority: Minor Fix For: 4.2.1 23.deque.special test fails because of STDCXX-635 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-360) [XLC++ 7.0] ICE compiling 2.smartptr.shared.cpp
[ https://issues.apache.org/jira/browse/STDCXX-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-360: Priority: Trivial (was: Major) Lowered Priority to Trivial. [XLC++ 7.0] ICE compiling 2.smartptr.shared.cpp --- Key: STDCXX-360 URL: https://issues.apache.org/jira/browse/STDCXX-360 Project: C++ Standard Library Issue Type: Bug Components: Tests Affects Versions: 4.1.3, 4.2.0 Environment: IBM XL C/C++ Version: 07.00..0009 Reporter: Martin Sebor Assignee: Travis Vitek Priority: Trivial Fix For: 4.2.1 Attachments: t.cpp.gz, t.cpp.gz.base64 PMR 02337,K78,000 The attached translation unit (gzipped and encoded in base-64) produced by preprocessing tests/tr1.util/2.smartptr.shared.cpp) causes an internal compiler error: $ xlC -qversion xlC -q64 -c -g t.cpp IBM XL C/C++ Enterprise Edition V7.0 Version: 07.00..0009 /nfs/packages/mdx/aix/compilers/5.3.0/va70_20070227/root/usr/vacpp/bin/.orig/xlC: 1501-230 Internal compiler error; please contact your Service Representative xlCcore_r -c -I/amd/devco/sebor/stdcxx-4.1.3/include/ansi -D_RWSTDDEBUG -D_RWSTD_USE_CONFIG -I/build/sebor/stdcxx-4.1.3-vacpp-7.0-15D/include -I/amd/devco/sebor/stdcxx-4.1.3/include -I/amd/devco/sebor/stdcxx-4.1.3/../rwtest -I/amd/devco/sebor/stdcxx-4.1.3/../rwtest/include -I/amd/devco/sebor/stdcxx-4.1.3/tests/include -g -q64 -qtemplateregistry=2.smartptr.shared.ti /amd/devco/sebor/stdcxx-4.1.3/tests/tr1.util/2.smartptr.shared.cpp /nfs/packages/mdx/aix/compilers/5.3.0/va70_20070227/root/usr/vacpp/bin/.orig/xlCcore_r: 1501-230 Internal compiler error; please contact your Service Representative -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-139) exception safety of algorithms not exercised
[ https://issues.apache.org/jira/browse/STDCXX-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-139: Affects Version/s: 4.2.0 Fix Version/s: (was: 4.2.1) 4.3 This seems far too big a project to do in the 4.2.1 timeframe. Deferred. exception safety of algorithms not exercised Key: STDCXX-139 URL: https://issues.apache.org/jira/browse/STDCXX-139 Project: C++ Standard Library Issue Type: Improvement Components: Tests Affects Versions: 4.1.3, 4.1.4, 4.2.0 Environment: all Reporter: Anton Pevtsov Priority: Minor Fix For: 4.3 It would be nice to enhance each algorithm's test with exception-safety tests, i.e. test the algorithm in cases when ctor, copy ctor or comparison operator throws an exception. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-626) [LWG #581] std::ostream::flush() unexpectedly calls to rdbuf()-sync() when rdstate() != goodbit
[ https://issues.apache.org/jira/browse/STDCXX-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor closed STDCXX-626. --- Resolution: Fixed Regression test added: http://svn.apache.org/viewcvs?view=revrev=611016 Fix committed: http://svn.apache.org/viewcvs?view=revrev=611019 Fix verified in nightly results. Merged to 4.2.1: http://svn.apache.org/viewcvs?view=revrev=612563 Closing. [LWG #581] std::ostream::flush() unexpectedly calls to rdbuf()-sync() when rdstate() != goodbit - Key: STDCXX-626 URL: https://issues.apache.org/jira/browse/STDCXX-626 Project: C++ Standard Library Issue Type: Bug Components: 27. Input/Output Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 Environment: All Reporter: Farid Zaripov Assignee: Martin Sebor Priority: Trivial Fix For: 4.2.1 The details are here: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#581 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-626) [LWG #581] std::ostream::flush() unexpectedly calls to rdbuf()-sync() when rdstate() != goodbit
[ https://issues.apache.org/jira/browse/STDCXX-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor reassigned STDCXX-626: --- Assignee: Martin Sebor [LWG #581] std::ostream::flush() unexpectedly calls to rdbuf()-sync() when rdstate() != goodbit - Key: STDCXX-626 URL: https://issues.apache.org/jira/browse/STDCXX-626 Project: C++ Standard Library Issue Type: Bug Components: 27. Input/Output Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 Environment: All Reporter: Farid Zaripov Assignee: Martin Sebor Priority: Trivial Fix For: 4.2.1 The details are here: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#581 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-138) algorithms complexity tests not strict enough
[ https://issues.apache.org/jira/browse/STDCXX-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-138: Affects Version/s: 4.2.0 Fix Version/s: (was: 4.2.1) 4.3 Like STDCXX-139, this also seems too big to do in the 4.2.1 timeframe. Deferred. algorithms complexity tests not strict enough - Key: STDCXX-138 URL: https://issues.apache.org/jira/browse/STDCXX-138 Project: C++ Standard Library Issue Type: Improvement Components: Tests Affects Versions: 4.1.3, 4.1.4, 4.2.0 Environment: all Reporter: Anton Pevtsov Priority: Minor Fix For: 4.3 Affects tests for sort, stable_sort, partial_sort, partial_sort_copy, nth_element, etc algorithms where the complexity is O(f(N)), where N is the length of the test sequence, f(N) - some function of N: log N, N log N, N. It is necessary to investigate each algorithm to find the worst case for it and use the complexity on this worst sequence as the upper bound in tests. Currently magic coefficients are used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-438) std::string::append (InputIterator, InputIterator) appending self incorrect
[
https://issues.apache.org/jira/browse/STDCXX-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Sebor updated STDCXX-438:
Severity: Incorrect Behavior
Affects Version/s: 4.1.4
4.2.0
Affects all released versions.
std::string::append (InputIterator, InputIterator) appending self incorrect
---
Key: STDCXX-438
URL: https://issues.apache.org/jira/browse/STDCXX-438
Project: C++ Standard Library
Issue Type: Bug
Components: 21. Strings
Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0
Environment: all
Reporter: Martin Sebor
Assignee: Farid Zaripov
Priority: Minor
Fix For: 4.2.1
The 21.string.append.cpp test has been failing a number of assertions for
self-referential test cases that exercise the ability to append a substring
of a string into itself using the append(InputIterator, InputIterator) member
template specialization for InputIterator being an actual Input Iterator. The
program below reproduces the problem in a small isolated test case.
$ cat t.cpp gmake t ./t
#include cassert
#include cstdlib
#include cstring
#include iterator
#include new
#include string
void* operator new (std::size_t n) throw (std::bad_alloc)
{
void* const ptr = std::malloc (n + sizeof n);
std::memset (ptr, -1, n);
*(std::size_t*)ptr = n;
return (std::size_t*)ptr + 1;
}
void operator delete (void *ptr) throw ()
{
std::memset (ptr, -1, *((std::size_t*)ptr - 1));
std::free ((std::size_t*)ptr - 1);
}
struct InputIterator: std::iteratorstd::input_iterator_tag, char
{
const char *p_;
InputIterator (const char *p): p_ (p) { }
char operator* () const { return *p_; }
InputIterator operator++ () { return ++p_, *this; }
InputIterator operator++ (int) {
return ++p_, InputIterator (p_ - 1);
}
bool operator== (const InputIterator rhs) const { return p_ == rhs.p_; }
};
int main ()
{
const char s[] = abc;
{
std::string str (s);
const char* p0 = s + 1;
const char* p1 = p0 + 1;
const InputIterator first (p0);
const InputIterator last (p1);
str.append (first, last);
assert (abcb == str);
}
{
std::string str (s);
const char* p0 = str.data () + 1;
const char* p1 = p0 + 1;
const InputIterator first (p0);
const InputIterator last (p1);
str.append (first, last);
assert (abcb == str);
}
}
aCC -c -I/amd/devco/sebor/stdcxx/include/ansi -I/usr/include -D_RWSTDDEBUG
-mt -D_RWSTD_USE_CONFIG -I/amd/devco/sebor/stdcxx/include
-I/build/sebor/stdcxx-aCC-3.73-15D/include
-I/amd/devco/sebor/stdcxx/tests/include -Aa +nostl -g +d +DD64 +w +W392
+W655 +W684 +W818 +W819 +W849 t.cpp
aCC t.o -o t -L/build/sebor/stdcxx-aCC-3.73-15D/rwtest -lrwtest15D -Aa +nostl
-Wl,+s -Wl,+vnocompatwarnings -mt +DD64
-L/build/sebor/stdcxx-aCC-3.73-15D/lib
-Wl,+b/build/sebor/stdcxx-aCC-3.73-15D/lib:/build/sebor/stdcxx-aCC-3.73-15D/rwtest
-lstd15D -lm
Assertion failed: abcb == str, file t.cpp, line 67
ABORT instruction (core dumped)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-366) Add benchmarking framework
[ https://issues.apache.org/jira/browse/STDCXX-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-366: Fix Version/s: (was: 4.2.1) 4.3 Nice to have but too much work for 4.2.1. Deferred. Add benchmarking framework -- Key: STDCXX-366 URL: https://issues.apache.org/jira/browse/STDCXX-366 Project: C++ Standard Library Issue Type: Wish Components: Tests Environment: N/A Reporter: Andrew Black Priority: Minor Fix For: 4.3 The Apache C++ Standard library is intended to be a high performance implementation of the C++ Standard Library. To this end, we have created a few benchmarking applications, but no systematic effort has been made to create a set of benchmarking executables, and no infrastructure exists to build and run such executables in a uniform manner. We should create a benchmarking infrastructure, modeled on the test infrastructure. This would likely include a makefile, some kind of benchmark runner (similar to the exec utility), a (thin) benchmark driver library, and a set of benchmark programs, each testing a particular class, method, or set of methods. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-458) limits example output depends on platform
[ https://issues.apache.org/jira/browse/STDCXX-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-458: Priority: Trivial (was: Minor) Affects Version/s: 4.2.0 Summary: limits example output depends on platform (was: limits example status depends on platform) Changed status to output in summary and added 4.2.0 to Affected Version/s. Bumped Priority to Trivial -- there's nothing wrong with the example or the library. The problem is with our test infrastructure which expects all examples to produce the same output regardless of the platform. We might want to think about a way to provide platform-specific expected output files for these kinds of examples. limits example output depends on platform - Key: STDCXX-458 URL: https://issues.apache.org/jira/browse/STDCXX-458 Project: C++ Standard Library Issue Type: Bug Components: Examples Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 Environment: All Reporter: Farid Zaripov Priority: Trivial Fix For: 4.2.1 The limits example expected to output inf for Infinity, nan for Quiet NAN and Signaling NAN. But actually the output depends on the platform (see STDCXX-51). The example should produce the inf for Infinity, the qnan for Quiet NAN and snan for Signaling NAN on all platforms (http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03703.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-527) publish LOC metrics
[ https://issues.apache.org/jira/browse/STDCXX-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-527: Attachment: stdcxx-4.2.0-sloc.txt Attached the output of David Wheeler's sloccount on stdcxx 4.2.0 sources. publish LOC metrics --- Key: STDCXX-527 URL: https://issues.apache.org/jira/browse/STDCXX-527 Project: C++ Standard Library Issue Type: Task Components: Web Affects Versions: 4.1.2, 4.1.3, 4.1.4 Reporter: Martin Sebor Assignee: Martin Sebor Priority: Minor Fix For: 4.2.1 Attachments: stdcxx-4.2.0-sloc.txt A recent project at work reminded me that it would be useful to keep track of LOC counts and other metrics for stdcxx on an ongoing basis and publish the data (perhaps in a graphical form) on the project web site. One tool that seems pretty popular for this purpose is David Wheeler's SLOCCount: http://www.dwheeler.com/sloccount/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-527) publish LOC metrics
[ https://issues.apache.org/jira/browse/STDCXX-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-527: Attachment: stdcxx-4.1.3-sloc.txt Attached sloccount output for stdcxx 4.1.3. publish LOC metrics --- Key: STDCXX-527 URL: https://issues.apache.org/jira/browse/STDCXX-527 Project: C++ Standard Library Issue Type: Task Components: Web Affects Versions: 4.1.2, 4.1.3, 4.1.4 Reporter: Martin Sebor Assignee: Martin Sebor Priority: Minor Fix For: 4.2.1 Attachments: stdcxx-4.1.3-sloc.txt, stdcxx-4.2.0-sloc.txt A recent project at work reminded me that it would be useful to keep track of LOC counts and other metrics for stdcxx on an ongoing basis and publish the data (perhaps in a graphical form) on the project web site. One tool that seems pretty popular for this purpose is David Wheeler's SLOCCount: http://www.dwheeler.com/sloccount/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-527) publish LOC metrics
[ https://issues.apache.org/jira/browse/STDCXX-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-527: Attachment: stdcxx-4.1.2-sloc.txt Attached sloccount output for the stdcxx 4.1.2 snapshot. publish LOC metrics --- Key: STDCXX-527 URL: https://issues.apache.org/jira/browse/STDCXX-527 Project: C++ Standard Library Issue Type: Task Components: Web Affects Versions: 4.1.2, 4.1.3, 4.1.4 Reporter: Martin Sebor Assignee: Martin Sebor Priority: Minor Fix For: 4.2.1 Attachments: stdcxx-4.1.2-sloc.txt, stdcxx-4.1.3-sloc.txt, stdcxx-4.2.0-sloc.txt A recent project at work reminded me that it would be useful to keep track of LOC counts and other metrics for stdcxx on an ongoing basis and publish the data (perhaps in a graphical form) on the project web site. One tool that seems pretty popular for this purpose is David Wheeler's SLOCCount: http://www.dwheeler.com/sloccount/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-527) publish LOC metrics
[ https://issues.apache.org/jira/browse/STDCXX-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559712#action_12559712 ] Martin Sebor commented on STDCXX-527: - Maybe we can add a link to the summary section from each of the attached files to the table on the Downloads page: http://incubator.apache.org/stdcxx/download.html#releases publish LOC metrics --- Key: STDCXX-527 URL: https://issues.apache.org/jira/browse/STDCXX-527 Project: C++ Standard Library Issue Type: Task Components: Web Affects Versions: 4.1.2, 4.1.3, 4.1.4 Reporter: Martin Sebor Assignee: Martin Sebor Priority: Minor Fix For: 4.2.1 Attachments: stdcxx-4.1.2-sloc.txt, stdcxx-4.1.3-sloc.txt, stdcxx-4.2.0-sloc.txt A recent project at work reminded me that it would be useful to keep track of LOC counts and other metrics for stdcxx on an ongoing basis and publish the data (perhaps in a graphical form) on the project web site. One tool that seems pretty popular for this purpose is David Wheeler's SLOCCount: http://www.dwheeler.com/sloccount/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-573) Enable building with Purify
[ https://issues.apache.org/jira/browse/STDCXX-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor reassigned STDCXX-573: --- Assignee: Travis Vitek Adding Purify to our nightly testing would be worthwhile, as would running valgrind on Linux. Travis, you might want to look at this to see if it makes sense. Enable building with Purify --- Key: STDCXX-573 URL: https://issues.apache.org/jira/browse/STDCXX-573 Project: C++ Standard Library Issue Type: Improvement Components: Build Affects Versions: 4.2.0 Reporter: Andrew Black Assignee: Travis Vitek Priority: Minor Fix For: 4.2.1 Attachments: purify.diff It would be useful to be able to build and run the examples, utilities and tests using Rational Purify. This could potentially allow us to detect errors, such as memory leaks, which we might not otherwise detect. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-696) Remove etc/config/configure.sh script from repository.
[ https://issues.apache.org/jira/browse/STDCXX-696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor closed STDCXX-696. --- I'm going to close this as Won't Fix on the assumption that we'll make use of the script when we finally get around to implementing STDCXX-260. Remove etc/config/configure.sh script from repository. -- Key: STDCXX-696 URL: https://issues.apache.org/jira/browse/STDCXX-696 Project: C++ Standard Library Issue Type: Task Components: Configuration Reporter: Eric Lemings Priority: Trivial From what I see, this file does absolutely nothing yet it is included as part of the distribution because it still resides in the repository. If it is no longer used, it should be deleted from the repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-686) redesign web site
[ https://issues.apache.org/jira/browse/STDCXX-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559135#action_12559135 ] Martin Sebor commented on STDCXX-686: - Some more discussion is here: http://www.nabble.com/Redesign-Website-td14838851.html redesign web site - Key: STDCXX-686 URL: https://issues.apache.org/jira/browse/STDCXX-686 Project: C++ Standard Library Issue Type: Improvement Components: Web Reporter: Martin Sebor The current web site is a bunch of static HTML pages with a lot of difficult-to-maintain formatting cruft copied from pages of another incubator project. We should look into generating the site from easier-to-maintain sources using a tool like Apache Forrest or some such. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-665) [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions
[ https://issues.apache.org/jira/browse/STDCXX-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559209#action_12559209 ] Martin Sebor commented on STDCXX-665: - I suggest bringing up the example on an AIX development newsgroup or forum: http://www-128.ibm.com/developerworks/forums/forum.jspa?forumID=905 As for the options, since we call setlocale() to initialize other facets I don't think calling the function from std::messages would make things any worse than they already are. Unless AIX requires that setlocale() be called before each call to catopen()? Does that change how you feel about (4)? [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions Key: STDCXX-665 URL: https://issues.apache.org/jira/browse/STDCXX-665 Project: C++ Standard Library Issue Type: Bug Components: Tests Affects Versions: 4.2.0 Reporter: Travis Vitek Assignee: Travis Vitek Fix For: 4.2.1 Attachments: stdcxx-665.patch Currently only single threaded builds show this problem NAME STATUS WARN ASSERTS FAILED PERCNTUSER SYSREAL 22.locale.messages 00 26810660% 0.090 0.640 3.960 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-665) [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions
[ https://issues.apache.org/jira/browse/STDCXX-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559271#action_12559271 ] Martin Sebor commented on STDCXX-665: - I'm inclined to view the C/POSIX case as an AIX bug. It would be good to have a confirmation from IBM that they agree. If they do, we'll have the option of documenting it as a limitation until IBM fixes (with the workaround being for programs to call setlocale(LC_ALL, some-name-other-than-C-or-POSIX) first). Otherwise, if it's by design and IBM won't fix it I'll feel more compelled to spend time trying to come up with a workaround. [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions Key: STDCXX-665 URL: https://issues.apache.org/jira/browse/STDCXX-665 Project: C++ Standard Library Issue Type: Bug Components: Tests Affects Versions: 4.2.0 Reporter: Travis Vitek Assignee: Travis Vitek Fix For: 4.2.1 Attachments: stdcxx-665.patch Currently only single threaded builds show this problem NAME STATUS WARN ASSERTS FAILED PERCNTUSER SYSREAL 22.locale.messages 00 26810660% 0.090 0.640 3.960 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-695) [HP aCC 6.15] lots of noise due to compiler remarks
[
https://issues.apache.org/jira/browse/STDCXX-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559342#action_12559342
]
Martin Sebor commented on STDCXX-695:
-
Dennis' comments:
Original Message
Subject: Re: aCC 6.15 bogus remark #3348
Date: Fri, 11 Jan 2008 18:03:44 -0800 (PST)
From: Dennis Handly [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
From: Martin Sebor [EMAIL PROTECTED]
We get over 800 of these remarks in each of our builds. I haven't
analyzed them all but I did reduce one to a test case showing that
at least in some instances the warning is wrong.
I've seen cases where it was right but we know what we are doing. :-)
And a few broken cases.
struct S { enum { X }; };
template class T
int foo() {
const int X = 1;
return X;
}
int main() { return fooint(); }
aCC: HP C/aC++ B3910B A.06.14 [Feb 22 2007]
line 4: remark #3348-D: declaration hides constant S::X (declared at line 1)
const int X = 1;
detected during instantiation of int fooT() [with T=int] at line 8
So this is an enum X that is in struct S, not even in scope here.
We released a new compiler A.06.15 in Sept, with a patch A.06.16 in Dec.
From: Xiaohua zhang [EMAIL PROTECTED]
This bug has been fixed in ToT, you can try next week's weekly tarball to
Martin doesn't get them.
From: Martin Sebor [EMAIL PROTECTED]
Btw., I just counted the number of remarks we get in stdcxx builds
with aCC 6.15 and put together a breakdown. You might find the
results interesting:
http://issues.apache.org/jira/browse/STDCXX-695
Well, interesting in that you haven't figured out that you should just
suppress some of them. ;-)
You do know that there is a command cadvise report logs ... that
can produce a nice summary??
#2177-D: 8 variable was declared but never referenced
#2550-D: 28 variable was set but never used
#2826-D: 44 parameter was never referenced
Suppress with +W2177,2550,2826.
#2181-D: 9 argument is incompatible with corresponding format string conversion
This is usually your bug.
#3235-D: 1 nonstandard conversion between pointer to function and pointer to
data
This isn't legal. You must use a type pun, or bigger hammer.
#3348-D: 799 declaration hides constant or variable
As you said, most are bogus.
#4219-D: 250 64 bit migration: type conversion may truncate value
#4298-D: 124 64 bit migration: addition result could be truncated before cast
to bigger sized type
#4299-D: 20 64 bit migration: multiply result could be truncated before cast to
bigger sized type
Probably not helpful. We have removed it from +wlint.
#4244-D: 4 extern storage class used with a function definition
A useless coding standard that no right thinking developer would want.
We are thinking of hiding it.
#4296-D: 695 arithmetic operation on boolean type
#4297-D: 1220 boolean value is used as array index
Another two that might not be useful.
#4282-D: 34 virtual function is called from constructor/destructor
A comment in that these aren't virtual.
#4300-D: 60 Overflow while computing constant in left shift operation
Probably a bug.
#4315-D: 60 while loop without body, did you insert an extra ';'?
An attempt to find typos.
[HP aCC 6.15] lots of noise due to compiler remarks
---
Key: STDCXX-695
URL: https://issues.apache.org/jira/browse/STDCXX-695
Project: C++ Standard Library
Issue Type: Bug
Components: Build
Affects Versions: 4.2.0
Environment: HP aCC 6.15
Reporter: Martin Sebor
The latest HP compiler on IPF issues lots of remarks, making our builds
exceedingly noisy.
Here's a breakdown of all the remarks we get in a recent 12S build along with
the number of each:
F=hpux-11.31-ia64-acc-6.15-12S-610576-log; \
R=`sed -n s/.*: remark \(#[1-9][0-9]*-.\): .*/\1/p $F | sort | uniq`; \
for r in $R; do \
n=`grep : remark $r: $F | wc -l`; echo $r: $n; \
done
#2177-D: 8 variable was declared but never referenced
#2181-D: 9 argument is incompatible with corresponding format string
conversion
#2550-D: 28 variable was set but never used
#2826-D: 44 parameter was never referenced
#2961-D: 1 use of a type with no linkage to declare a variable with linkage
#3235-D: 1 nonstandard conversion between pointer to function and pointer
to data
#3348-D: 799 declaration hides constant or variable
#4217-D: 3 comparison of enum (represented as an unsigned integer) with zero
#4219-D: 250 64 bit migration: type conversion may truncate value
#4234-D: 28 type conversion may lose significant bits
#4239-D: 2 case type mismatch with switch expression type
#4244-D: 4 extern storage class used with a function definition
#4248-D: 4 comparison of unsigned integer with a signed integer
#4271-D: 780 type conversion may
[jira] Updated: (STDCXX-699) [HP aCC 6.15] remark #4282: fstream ctor calls virtual setbuf()
[ https://issues.apache.org/jira/browse/STDCXX-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-699: Severity: (was: Compiler Warning) Issue Type: Sub-task (was: Bug) Parent: STDCXX-695 [HP aCC 6.15] remark #4282: fstream ctor calls virtual setbuf() --- Key: STDCXX-699 URL: https://issues.apache.org/jira/browse/STDCXX-699 Project: C++ Standard Library Issue Type: Sub-task Components: 27. Input/Output Affects Versions: 4.2.0 Reporter: Martin Sebor Priority: Minor Fix For: 4.2.1 HP aCC 6.15 issues a remark noting that basic_filebuf ctor calls the virtual member function setbuf(). The purpose of the remark is to warn that the usual virtual dispatch doesn't take place for virtual function calls from class ctors (i.e., the function defined the ctor's class is called). We should silence the remark by qualifying the call with the name of the class. aCC -c -I$(TOPDIR)/include -I$(BUILDDIR)/include -AA +O2 +DD64 +w +W392 +W655 +W684 +W818 +W819 +W849 +W2193 +W2236 +W2261 +W2340 +W2401 +W2487 +W4227 +W4229 +W4231 +W4235 +W4237 +W4249 +W4255 +W4272 +W4284 +W4285 +W4286 +Z $(TOPDIR)/src/ti_filebuf.cpp $(TOPDIR)/include/fstream, line 112: remark #4282-D: virtual function is called from constructor/destructor setbuf (0, _RWSTD_DEFAULT_BUFSIZE); ^ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-699) [HP aCC 6.15] remark #4282: fstream ctor calls virtual setbuf()
[HP aCC 6.15] remark #4282: fstream ctor calls virtual setbuf() --- Key: STDCXX-699 URL: https://issues.apache.org/jira/browse/STDCXX-699 Project: C++ Standard Library Issue Type: Bug Components: 27. Input/Output Affects Versions: 4.2.0 Reporter: Martin Sebor Priority: Minor Fix For: 4.2.1 HP aCC 6.15 issues a remark noting that basic_filebuf ctor calls the virtual member function setbuf(). The purpose of the remark is to warn that the usual virtual dispatch doesn't take place for virtual function calls from class ctors (i.e., the function defined the ctor's class is called). We should silence the remark by qualifying the call with the name of the class. aCC -c -I$(TOPDIR)/include -I$(BUILDDIR)/include -AA +O2 +DD64 +w +W392 +W655 +W684 +W818 +W819 +W849 +W2193 +W2236 +W2261 +W2340 +W2401 +W2487 +W4227 +W4229 +W4231 +W4235 +W4237 +W4249 +W4255 +W4272 +W4284 +W4285 +W4286 +Z $(TOPDIR)/src/ti_filebuf.cpp $(TOPDIR)/include/fstream, line 112: remark #4282-D: virtual function is called from constructor/destructor setbuf (0, _RWSTD_DEFAULT_BUFSIZE); ^ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-699) [HP aCC 6.15] remark #4282: fstream ctor calls virtual setbuf()
[ https://issues.apache.org/jira/browse/STDCXX-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor reassigned STDCXX-699: --- Assignee: Martin Sebor [HP aCC 6.15] remark #4282: fstream ctor calls virtual setbuf() --- Key: STDCXX-699 URL: https://issues.apache.org/jira/browse/STDCXX-699 Project: C++ Standard Library Issue Type: Sub-task Components: 27. Input/Output Affects Versions: 4.2.0 Reporter: Martin Sebor Assignee: Martin Sebor Priority: Minor Fix For: 4.2.1 HP aCC 6.15 issues a remark noting that basic_filebuf ctor calls the virtual member function setbuf(). The purpose of the remark is to warn that the usual virtual dispatch doesn't take place for virtual function calls from class ctors (i.e., the function defined the ctor's class is called). We should silence the remark by qualifying the call with the name of the class. aCC -c -I$(TOPDIR)/include -I$(BUILDDIR)/include -AA +O2 +DD64 +w +W392 +W655 +W684 +W818 +W819 +W849 +W2193 +W2236 +W2261 +W2340 +W2401 +W2487 +W4227 +W4229 +W4231 +W4235 +W4237 +W4249 +W4255 +W4272 +W4284 +W4285 +W4286 +Z $(TOPDIR)/src/ti_filebuf.cpp $(TOPDIR)/include/fstream, line 112: remark #4282-D: virtual function is called from constructor/destructor setbuf (0, _RWSTD_DEFAULT_BUFSIZE); ^ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-700) [HP aCC 6.15] remark #2181-D: argument is incompatible with corresponding format string conversion
[HP aCC 6.15] remark #2181-D: argument is incompatible with corresponding format string conversion -- Key: STDCXX-700 URL: https://issues.apache.org/jira/browse/STDCXX-700 Project: C++ Standard Library Issue Type: Sub-task Components: Tests, Utilities Reporter: Martin Sebor Priority: Minor Several tests and the locale and locale utilities produce remark #2181-D: argument is incompatible with corresponding format string conversion: $ gunzip -c hpux-11.31-ia64-acc-6.15-8D-610576-log.gz | grep remark #2181-D$(TOPDIR)/util/locale.cpp, line 925: remark #2181-D: argument is incompatible with corresponding format string conversion $(TOPDIR)/util/ctype.cpp, line 255: remark #2181-D: argument is incompatible with corresponding format string conversion $(TOPDIR)/tests/src/qestream.cpp, line 136: remark #2181-D: argument is incompatible with corresponding format string conversion $(TOPDIR)/tests/support/18.numeric.special.int.cpp, line 324: remark #2181-D: argument is incompatible with corresponding format string conversion $(TOPDIR)/tests/utilities/20.temp.buffer.mt.cpp, line 129: remark #2181-D: argument is incompatible with corresponding format string conversion $(TOPDIR)/tests/localization/22.locale.codecvt.out.cpp, line 223: remark #2181-D: argument is incompatible with corresponding format string conversion $(TOPDIR)/tests/localization/22.locale.codecvt.out.cpp, line 245: remark #2181-D: argument is incompatible with corresponding format string conversion $(TOPDIR)/tests/localization/22.locale.time.get.cpp, line 1233: remark #2181-D: argument is incompatible with corresponding format string conversion $(TOPDIR)/tests/localization/22.locale.time.put.cpp, line 588: remark #2181-D: argument is incompatible with corresponding format string conversion -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-686) redesign web site
[ https://issues.apache.org/jira/browse/STDCXX-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12558650#action_12558650 ] Martin Sebor commented on STDCXX-686: - Okay, I'll work on that. Oddly, I don't see your request to subscribe. Unless someone else has already approved it could you try again? redesign web site - Key: STDCXX-686 URL: https://issues.apache.org/jira/browse/STDCXX-686 Project: C++ Standard Library Issue Type: Improvement Components: Web Reporter: Martin Sebor The current web site is a bunch of static HTML pages with a lot of difficult-to-maintain formatting cruft copied from pages of another incubator project. We should look into generating the site from easier-to-maintain sources using a tool like Apache Forrest or some such. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-692) [gcc 4.0.1/Mac OS X 10.5.1 Leopard] 25.search test failure
[ https://issues.apache.org/jira/browse/STDCXX-692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12558765#action_12558765 ] Martin Sebor commented on STDCXX-692: - Can you include build type info and a stack trace? [gcc 4.0.1/Mac OS X 10.5.1 Leopard] 25.search test failure -- Key: STDCXX-692 URL: https://issues.apache.org/jira/browse/STDCXX-692 Project: C++ Standard Library Issue Type: Bug Components: Tests Affects Versions: 4.2.0 Environment: Darwin hostname 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct 31 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386 i386 Reporter: Eric Lemings Priority: Minor Fix For: 4.2.1 This test program crashes with a bus error on Apple's latest cat. Don't know any more than that. Just filing an issue for tracking purposes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-686) redesign web site
[ https://issues.apache.org/jira/browse/STDCXX-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12558488#action_12558488 ] Martin Sebor commented on STDCXX-686: - That'd be awesome! I've experimented with Forrest and it seems that it would fit our needs almost exactly. Based on playing with the demo it looked to me like the best way to start is to modify it by replacing the pages that come with it with our content (all we have at this point is 4 pages). Do you agree or would you suggest a different approach when migrating our site? redesign web site - Key: STDCXX-686 URL: https://issues.apache.org/jira/browse/STDCXX-686 Project: C++ Standard Library Issue Type: Improvement Components: Web Reporter: Martin Sebor The current web site is a bunch of static HTML pages with a lot of difficult-to-maintain formatting cruft copied from pages of another incubator project. We should look into generating the site from easier-to-maintain sources using a tool like Apache Forrest or some such. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-693) std::valarray::sum does not work correctly for udt that has nonzero default value
[
https://issues.apache.org/jira/browse/STDCXX-693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12558018#action_12558018
]
Martin Sebor commented on STDCXX-693:
-
FWIW, I also did most of this as part of the big valarray rewrite last year.
None of it is checked in because it's binary incompatible. That said, I have no
problem committing improvements to valarray piecemeal, just as long as they're
compatible, and leaving the breaking changes for last (5.0).
Since it sounds like we've both made some of the same changes it might make
sense to compare our approaches. If you agree, I suggest you post your patch to
the list before committing it to give me a chance to review it.
Incidentally, since we're outlining a function in the patch, it wouldn't be a
forward compatible change, would it?
std::valarray::sum does not work correctly for udt that has nonzero default
value
-
Key: STDCXX-693
URL: https://issues.apache.org/jira/browse/STDCXX-693
Project: C++ Standard Library
Issue Type: Bug
Components: 26. Numerics
Affects Versions: 4.2.0
Reporter: Travis Vitek
Priority: Minor
#include cassert
#include valarray
struct S
{
// this ctor should not be required
S ()
: value (21)
{
}
S (int v)
: value (v)
{
}
S (const S rhs)
: value (rhs.value)
{
}
S operator+= (const S rhs)
{
value += rhs.value;
return *this;
}
int value;
};
int main ()
{
const std::valarrayS b (S (10), 1); // 10 elements with value 1
assert (b.sum ().value == 10);
return 0;
}
The wording in the standard seems to imply that the returned value should be
a copy of one of the elements, and that op+= should be called on all of the
other elements. If this is the case, then this an additional issue that would
be detectable in user code [the user can count how many times the op+= is
invoked]. This issue may apply to the min() and max() methods as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-694) [HP aCC 6.15] bogus remark #3348
[HP aCC 6.15] bogus remark #3348
Key: STDCXX-694
URL: https://issues.apache.org/jira/browse/STDCXX-694
Project: C++ Standard Library
Issue Type: Bug
Components: External
Environment: HP aCC 6.15/HP-UX
Reporter: Martin Sebor
Priority: Minor
The remark in the program below is obviously bogus:
$ cat t.cpp aCC -V +w t.cpp
struct S { enum { X }; };
template class T
int foo () {
const int X = 1;
return X;
}
int main () { return fooint(); }
aCC: HP C/aC++ B3910B A.06.14 [Feb 22 2007]
t.cpp, line 4: remark #3348-D: declaration hides constant S::X (declared at
line 1)
const int X = 1;
^
detected during instantiation of int fooT() [with T=int] at line 8
ld: 92453-07 linker ld HP Itanium(R) B.12.43 IPF/IPF
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-695) [HP aCC 6.15] lots of noise due to compiler remarks
[HP aCC 6.15] lots of noise due to compiler remarks --- Key: STDCXX-695 URL: https://issues.apache.org/jira/browse/STDCXX-695 Project: C++ Standard Library Issue Type: Bug Components: Build Affects Versions: 4.2.0 Environment: HP aCC 6.15 Reporter: Martin Sebor The latest HP compiler on IPF issues lots of remarks, making our builds exceedingly noisy. Here's a breakdown of all the remarks we get in a recent 12S build along with the number of each: F=hpux-11.31-ia64-acc-6.15-12S-610576-log; \ R=`sed -n s/.*: remark \(#[1-9][0-9]*-.\): .*/\1/p $F | sort | uniq`; \ for r in $R; do \ n=`grep : remark $r: $F | wc -l`; echo $r: $n; \ done #2177-D: 8 variable was declared but never referenced #2181-D: 9 argument is incompatible with corresponding format string conversion #2550-D: 28 variable was set but never used #2826-D: 44 parameter was never referenced #2961-D: 1 use of a type with no linkage to declare a variable with linkage #3235-D: 1 nonstandard conversion between pointer to function and pointer to data #3348-D: 799 declaration hides constant or variable #4217-D: 3 comparison of enum (represented as an unsigned integer) with zero #4219-D: 250 64 bit migration: type conversion may truncate value #4234-D: 28 type conversion may lose significant bits #4239-D: 2 case type mismatch with switch expression type #4244-D: 4 extern storage class used with a function definition #4248-D: 4 comparison of unsigned integer with a signed integer #4271-D: 780 type conversion may lose sign #4273-D: 18 floating-point equality and inequality comparisons may be inappropriate due to roundoff common in floating-point computation #4278-D: 3 the subexpression in logical expression is a constant #4282-D: 34 virtual function is called from constructor/destructor #4283-D: 3 access global variable in constructor #4296-D: 695 arithmetic operation on boolean type #4297-D: 1220 boolean value is used as array index #4298-D: 124 64 bit migration: addition result could be truncated before cast to bigger sized type #4299-D: 20 64 bit migration: multiply result could be truncated before cast to bigger sized type #4300-D: 60 Overflow while computing constant in left shift operation #4315-D: 60 while loop without body, did you insert an extra ';'? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-499) std::num_put inserts NUL thousand separator
[
https://issues.apache.org/jira/browse/STDCXX-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Sebor reassigned STDCXX-499:
---
Assignee: Martin Sebor
std::num_put inserts NUL thousand separator
---
Key: STDCXX-499
URL: https://issues.apache.org/jira/browse/STDCXX-499
Project: C++ Standard Library
Issue Type: Bug
Components: 22. Localization
Affects Versions: 4.1.2, 4.1.3, 4.1.4
Reporter: Martin Sebor
Assignee: Martin Sebor
Fix For: 4.2.1
Moved from Rogue Wave Bugzilla:
http://bugzilla.cvo.roguewave.com/show_bug.cgi?id=1913
Original Message
Subject: num_put and null-character thousand separator
Date: Tue, 11 Jan 2005 16:10:23 -0500
From: Boris Gubenko [EMAIL PROTECTED]
Reply-To: Boris Gubenko [EMAIL PROTECTED]
Organization: Hewlett-Packard Co.
To: Martin Sebor [EMAIL PROTECTED]
Another locale-related issue that we fixed in rw stdlib v3.0 (and in
v2.0 also) is making sure, that num_put does not insert null thousand
separator character into the stream. Here is the fix in _num_put.cc
in v3.0 :
template class _CharT, class _OutputIter /* = ostreambuf_iterator_CharT
*/
_TYPENAME num_put_CharT, _OutputIter::iter_type
num_put_CharT, _OutputIter::
_C_put (iter_type __it, ios_base __flags, char_type __fill, int __type,
const void *__pval) const
{
const numpunctchar_type __np =
_V3_USE_FACET (numpunctchar_type, __flags.getloc ());
// FIXME: adjust buffer dynamically as necessary
char __buf [_RWSTD_DBL_MAX_10_EXP];
char *__pbuf = __buf;
const string __grouping = __np.grouping ();
const char *__grp = __grouping.c_str ();
const int __prec= __flags.precision ();
#if defined(__VMS) defined(__DECCXX) !defined(__DECFIXCXXL1730)
const char __nogrouping = _RWSTD_CHAR_MAX;
if (!__np.thousands_sep())
__grp = __nogrouping;
#endif
Here is the test:
cosf.zko.dec.com setenv LANG fr_FR.ISO8859-1
cosf.zko.dec.com locale -k thousands_sep
thousands_sep=
cosf.zko.dec.com cxx x.cxx a.out
null character thousand_sep was not inserted
cosf.zko.dec.com cxx x.cxx -D_RWSTD_USE_CONFIG -D_RWSTDDEBUG \
-I/usr/cxx1/boris/CXXL_1886-2/stdlib-4.0/stdlib/include/ \
-nocxxstd -L/usr/cxx1/boris/CXXL_1886-2/result/lib -lstd11s \
a.out
null character thousand_sep was inserted
cosf.zko.dec.com
x.cxx
-
#ifndef __USE_STD_IOSTREAM
#define __USE_STD_IOSTREAM
#endif
#include iostream
#include sstream
#include string
#include locale
#include locale.h
#ifdef __linux
#define FRENCH_LOCALE fr_FR
#else
#define FRENCH_LOCALE fr_FR.ISO8859-1
#endif
using namespace std;
int main()
{
ostringstream os;
if (setlocale(LC_ALL,FRENCH_LOCALE))
{
setlocale(LC_ALL,C);
os.imbue(locale(FRENCH_LOCALE));
os (double) 1.1 endl;
if ( (os.str())[2] == '\0' )
cout null character thousand_sep was inserted endl;
else
cout null character thousand_sep was not inserted endl;
}
return 0;
}
--- Additional Comments From [EMAIL PROTECTED] 2005-01-11 14:50:44
Original Message
Subject: Re: num_put and null-character thousand separator
Date: Tue, 11 Jan 2005 15:50:06 -0700
From: Martin Sebor [EMAIL PROTECTED]
To: Boris Gubenko [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
Boris Gubenko wrote:
Another locale-related issue that we fixed in rw stdlib v3.0 (and in
v2.0 also) is making sure, that num_put does not insert null thousand
separator character into the stream. Here is the fix in _num_put.cc
in v3.0 :
I don't think this fix would be quite correct in general. NUL is
a valid character that the locale library was specifically designed
to be able to insert and extract just like any other. In addition,
in the code below, operator==() need not be defined for the character
type.
...
Here is the test:
Thanks for the helpful test case.
My feeling is that this case points out a fundamental design
disconnect between the C and C++ locales. In C, NUL is not
an ordinary character -- it's a special character that terminates
strings. In addition, C formatted I/O is done in multibyte
characters. In contrast, in C++, NUL is a character like any other
and formatted I/O is always done in single chars (or wchar_t when
char is not wide enough), but never in multibyte characters.
In C, the thousand separator is a multibyte string so even if
grouping is non-empty, inserting an empty string will be as good
as inserting none at all. In C++ the separator is assumed to be
a single character so there's no way to achieve the same effect.
Instead, whether a thousand separator gets inserted or not is
controlled by the grouping string.
One way to fix this would be to set
[jira] Commented: (STDCXX-499) std::num_put inserts NUL thousand separator
[
https://issues.apache.org/jira/browse/STDCXX-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12557810#action_12557810
]
Martin Sebor commented on STDCXX-499:
-
Here's a test case that reproduces the same behavior with the bg_BG locale on
Linux:
$ cat t.cpp make t cat /etc/redhat-release ./t | od -c
#include cassert
#include iostream
#include locale
#include sstream
#include string
int main ()
{
std::stringstream strm;
strm.imbue (std::locale (bg_BG));
strm 123456;
const std::string s = strm.str ();
std::cout s '\n';
assert (s.npos == s.find ('\0'));
}
gcc -c -I/amd/devco/sebor/stdcxx/include/ansi -D_RWSTDDEBUG -pthread
-I/amd/devco/sebor/stdcxx/include -I/build/sebor/stdcxx-gcc-3.4.6_3-15D/include
-I/amd/devco/sebor/stdcxx/examples/include -pedantic -nostdinc++ -g -W -Wall
-Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align
t.cpp
gcc t.o -o t -pthread -L/build/sebor/stdcxx-gcc-3.4.6_3-15D/lib
-Wl,-R/build/sebor/stdcxx-gcc-3.4.6_3-15D/lib -lstd15D -lsupc++ -lm
Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
t: t.cpp:19: int main(): Assertion `s.npos == s.find ('\0')' failed.
000 1 2 3 \0 4 5 6 \n
010
std::num_put inserts NUL thousand separator
---
Key: STDCXX-499
URL: https://issues.apache.org/jira/browse/STDCXX-499
Project: C++ Standard Library
Issue Type: Bug
Components: 22. Localization
Affects Versions: 4.1.2, 4.1.3, 4.1.4
Reporter: Martin Sebor
Fix For: 4.2.1
Moved from Rogue Wave Bugzilla:
http://bugzilla.cvo.roguewave.com/show_bug.cgi?id=1913
Original Message
Subject: num_put and null-character thousand separator
Date: Tue, 11 Jan 2005 16:10:23 -0500
From: Boris Gubenko [EMAIL PROTECTED]
Reply-To: Boris Gubenko [EMAIL PROTECTED]
Organization: Hewlett-Packard Co.
To: Martin Sebor [EMAIL PROTECTED]
Another locale-related issue that we fixed in rw stdlib v3.0 (and in
v2.0 also) is making sure, that num_put does not insert null thousand
separator character into the stream. Here is the fix in _num_put.cc
in v3.0 :
template class _CharT, class _OutputIter /* = ostreambuf_iterator_CharT
*/
_TYPENAME num_put_CharT, _OutputIter::iter_type
num_put_CharT, _OutputIter::
_C_put (iter_type __it, ios_base __flags, char_type __fill, int __type,
const void *__pval) const
{
const numpunctchar_type __np =
_V3_USE_FACET (numpunctchar_type, __flags.getloc ());
// FIXME: adjust buffer dynamically as necessary
char __buf [_RWSTD_DBL_MAX_10_EXP];
char *__pbuf = __buf;
const string __grouping = __np.grouping ();
const char *__grp = __grouping.c_str ();
const int __prec= __flags.precision ();
#if defined(__VMS) defined(__DECCXX) !defined(__DECFIXCXXL1730)
const char __nogrouping = _RWSTD_CHAR_MAX;
if (!__np.thousands_sep())
__grp = __nogrouping;
#endif
Here is the test:
cosf.zko.dec.com setenv LANG fr_FR.ISO8859-1
cosf.zko.dec.com locale -k thousands_sep
thousands_sep=
cosf.zko.dec.com cxx x.cxx a.out
null character thousand_sep was not inserted
cosf.zko.dec.com cxx x.cxx -D_RWSTD_USE_CONFIG -D_RWSTDDEBUG \
-I/usr/cxx1/boris/CXXL_1886-2/stdlib-4.0/stdlib/include/ \
-nocxxstd -L/usr/cxx1/boris/CXXL_1886-2/result/lib -lstd11s \
a.out
null character thousand_sep was inserted
cosf.zko.dec.com
x.cxx
-
#ifndef __USE_STD_IOSTREAM
#define __USE_STD_IOSTREAM
#endif
#include iostream
#include sstream
#include string
#include locale
#include locale.h
#ifdef __linux
#define FRENCH_LOCALE fr_FR
#else
#define FRENCH_LOCALE fr_FR.ISO8859-1
#endif
using namespace std;
int main()
{
ostringstream os;
if (setlocale(LC_ALL,FRENCH_LOCALE))
{
setlocale(LC_ALL,C);
os.imbue(locale(FRENCH_LOCALE));
os (double) 1.1 endl;
if ( (os.str())[2] == '\0' )
cout null character thousand_sep was inserted endl;
else
cout null character thousand_sep was not inserted endl;
}
return 0;
}
--- Additional Comments From [EMAIL PROTECTED] 2005-01-11 14:50:44
Original Message
Subject: Re: num_put and null-character thousand separator
Date: Tue, 11 Jan 2005 15:50:06 -0700
From: Martin Sebor [EMAIL PROTECTED]
To: Boris Gubenko [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
Boris Gubenko wrote:
Another locale-related issue that we fixed in rw stdlib v3.0 (and in
v2.0 also) is making sure, that num_put does not insert null thousand
separator character into the stream. Here is the fix in _num_put.cc
in v3.0 :
I don't think this fix would be quite correct in general. NUL is
a valid character that the locale library was specifically designed
to be
[jira] Commented: (STDCXX-499) std::num_put inserts NUL thousand separator
[
https://issues.apache.org/jira/browse/STDCXX-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12557859#action_12557859
]
Martin Sebor commented on STDCXX-499:
-
The question is: is this our problem or one with the locale definition (such as
the Bulgarian locale on Linux in the test case above). I.e., is it a valid
locale that specifies a grouping but no thousands_sep?
Among our own locales there is only one that fits this description suggesting
it might be a bug in the locale definition:
$ (cd ~/stdcxx for f in `grep -l ^grouping *[1-9] etc/nls/src/*`; do grep
-l thousands_sep *\\ $f; done)
etc/nls/src/bg_BG
The latest glibc bg_BG definition is the same:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/localedata/locales/bg_BG?rev=1.7.2.2content-type=text/x-cvsweb-markupcvsroot=glibc
I opened a glibc issue to see if they agree it's a bug:
http://sources.redhat.com/bugzilla/show_bug.cgi?id=5599
If we should decide to work around it I see two possible ways of handling it in
punct.cpp, after retrieving the grouping and thousands_sep for the locale using
localeconv():
When grouping is not empty and valid and thsousands_sep is NUL, either
a) set grouping to , or
b) set thousands_sep to some non-NUL value.
Solution a) seems safer because it doesn't involve inventing a thousands_sep
that's valid for the locale but the downside is that it loses potentially
useful information.
Solution b) leaves open the question of which thousands_sep is appropriate for
the locale.
std::num_put inserts NUL thousand separator
---
Key: STDCXX-499
URL: https://issues.apache.org/jira/browse/STDCXX-499
Project: C++ Standard Library
Issue Type: Bug
Components: 22. Localization
Affects Versions: 4.1.2, 4.1.3, 4.1.4
Reporter: Martin Sebor
Assignee: Martin Sebor
Fix For: 4.2.1
Moved from Rogue Wave Bugzilla:
http://bugzilla.cvo.roguewave.com/show_bug.cgi?id=1913
Original Message
Subject: num_put and null-character thousand separator
Date: Tue, 11 Jan 2005 16:10:23 -0500
From: Boris Gubenko [EMAIL PROTECTED]
Reply-To: Boris Gubenko [EMAIL PROTECTED]
Organization: Hewlett-Packard Co.
To: Martin Sebor [EMAIL PROTECTED]
Another locale-related issue that we fixed in rw stdlib v3.0 (and in
v2.0 also) is making sure, that num_put does not insert null thousand
separator character into the stream. Here is the fix in _num_put.cc
in v3.0 :
template class _CharT, class _OutputIter /* = ostreambuf_iterator_CharT
*/
_TYPENAME num_put_CharT, _OutputIter::iter_type
num_put_CharT, _OutputIter::
_C_put (iter_type __it, ios_base __flags, char_type __fill, int __type,
const void *__pval) const
{
const numpunctchar_type __np =
_V3_USE_FACET (numpunctchar_type, __flags.getloc ());
// FIXME: adjust buffer dynamically as necessary
char __buf [_RWSTD_DBL_MAX_10_EXP];
char *__pbuf = __buf;
const string __grouping = __np.grouping ();
const char *__grp = __grouping.c_str ();
const int __prec= __flags.precision ();
#if defined(__VMS) defined(__DECCXX) !defined(__DECFIXCXXL1730)
const char __nogrouping = _RWSTD_CHAR_MAX;
if (!__np.thousands_sep())
__grp = __nogrouping;
#endif
Here is the test:
cosf.zko.dec.com setenv LANG fr_FR.ISO8859-1
cosf.zko.dec.com locale -k thousands_sep
thousands_sep=
cosf.zko.dec.com cxx x.cxx a.out
null character thousand_sep was not inserted
cosf.zko.dec.com cxx x.cxx -D_RWSTD_USE_CONFIG -D_RWSTDDEBUG \
-I/usr/cxx1/boris/CXXL_1886-2/stdlib-4.0/stdlib/include/ \
-nocxxstd -L/usr/cxx1/boris/CXXL_1886-2/result/lib -lstd11s \
a.out
null character thousand_sep was inserted
cosf.zko.dec.com
x.cxx
-
#ifndef __USE_STD_IOSTREAM
#define __USE_STD_IOSTREAM
#endif
#include iostream
#include sstream
#include string
#include locale
#include locale.h
#ifdef __linux
#define FRENCH_LOCALE fr_FR
#else
#define FRENCH_LOCALE fr_FR.ISO8859-1
#endif
using namespace std;
int main()
{
ostringstream os;
if (setlocale(LC_ALL,FRENCH_LOCALE))
{
setlocale(LC_ALL,C);
os.imbue(locale(FRENCH_LOCALE));
os (double) 1.1 endl;
if ( (os.str())[2] == '\0' )
cout null character thousand_sep was inserted endl;
else
cout null character thousand_sep was not inserted endl;
}
return 0;
}
--- Additional Comments From [EMAIL PROTECTED] 2005-01-11 14:50:44
Original Message
Subject: Re: num_put and null-character thousand separator
Date: Tue, 11 Jan 2005 15:50:06 -0700
From: Martin Sebor [EMAIL PROTECTED]
To: Boris Gubenko [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
Boris Gubenko wrote:
Another locale-related issue that we fixed in rw stdlib
[jira] Commented: (STDCXX-499) std::num_put inserts NUL thousand separator
[
https://issues.apache.org/jira/browse/STDCXX-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12557865#action_12557865
]
Martin Sebor commented on STDCXX-499:
-
It looks like GNU libstdc++ implements solution a) above. I opened an issue for
the mismatch between the libc grouping value and what libstdc++ returns:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
std::num_put inserts NUL thousand separator
---
Key: STDCXX-499
URL: https://issues.apache.org/jira/browse/STDCXX-499
Project: C++ Standard Library
Issue Type: Bug
Components: 22. Localization
Affects Versions: 4.1.2, 4.1.3, 4.1.4
Reporter: Martin Sebor
Assignee: Martin Sebor
Fix For: 4.2.1
Moved from Rogue Wave Bugzilla:
http://bugzilla.cvo.roguewave.com/show_bug.cgi?id=1913
Original Message
Subject: num_put and null-character thousand separator
Date: Tue, 11 Jan 2005 16:10:23 -0500
From: Boris Gubenko [EMAIL PROTECTED]
Reply-To: Boris Gubenko [EMAIL PROTECTED]
Organization: Hewlett-Packard Co.
To: Martin Sebor [EMAIL PROTECTED]
Another locale-related issue that we fixed in rw stdlib v3.0 (and in
v2.0 also) is making sure, that num_put does not insert null thousand
separator character into the stream. Here is the fix in _num_put.cc
in v3.0 :
template class _CharT, class _OutputIter /* = ostreambuf_iterator_CharT
*/
_TYPENAME num_put_CharT, _OutputIter::iter_type
num_put_CharT, _OutputIter::
_C_put (iter_type __it, ios_base __flags, char_type __fill, int __type,
const void *__pval) const
{
const numpunctchar_type __np =
_V3_USE_FACET (numpunctchar_type, __flags.getloc ());
// FIXME: adjust buffer dynamically as necessary
char __buf [_RWSTD_DBL_MAX_10_EXP];
char *__pbuf = __buf;
const string __grouping = __np.grouping ();
const char *__grp = __grouping.c_str ();
const int __prec= __flags.precision ();
#if defined(__VMS) defined(__DECCXX) !defined(__DECFIXCXXL1730)
const char __nogrouping = _RWSTD_CHAR_MAX;
if (!__np.thousands_sep())
__grp = __nogrouping;
#endif
Here is the test:
cosf.zko.dec.com setenv LANG fr_FR.ISO8859-1
cosf.zko.dec.com locale -k thousands_sep
thousands_sep=
cosf.zko.dec.com cxx x.cxx a.out
null character thousand_sep was not inserted
cosf.zko.dec.com cxx x.cxx -D_RWSTD_USE_CONFIG -D_RWSTDDEBUG \
-I/usr/cxx1/boris/CXXL_1886-2/stdlib-4.0/stdlib/include/ \
-nocxxstd -L/usr/cxx1/boris/CXXL_1886-2/result/lib -lstd11s \
a.out
null character thousand_sep was inserted
cosf.zko.dec.com
x.cxx
-
#ifndef __USE_STD_IOSTREAM
#define __USE_STD_IOSTREAM
#endif
#include iostream
#include sstream
#include string
#include locale
#include locale.h
#ifdef __linux
#define FRENCH_LOCALE fr_FR
#else
#define FRENCH_LOCALE fr_FR.ISO8859-1
#endif
using namespace std;
int main()
{
ostringstream os;
if (setlocale(LC_ALL,FRENCH_LOCALE))
{
setlocale(LC_ALL,C);
os.imbue(locale(FRENCH_LOCALE));
os (double) 1.1 endl;
if ( (os.str())[2] == '\0' )
cout null character thousand_sep was inserted endl;
else
cout null character thousand_sep was not inserted endl;
}
return 0;
}
--- Additional Comments From [EMAIL PROTECTED] 2005-01-11 14:50:44
Original Message
Subject: Re: num_put and null-character thousand separator
Date: Tue, 11 Jan 2005 15:50:06 -0700
From: Martin Sebor [EMAIL PROTECTED]
To: Boris Gubenko [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
Boris Gubenko wrote:
Another locale-related issue that we fixed in rw stdlib v3.0 (and in
v2.0 also) is making sure, that num_put does not insert null thousand
separator character into the stream. Here is the fix in _num_put.cc
in v3.0 :
I don't think this fix would be quite correct in general. NUL is
a valid character that the locale library was specifically designed
to be able to insert and extract just like any other. In addition,
in the code below, operator==() need not be defined for the character
type.
...
Here is the test:
Thanks for the helpful test case.
My feeling is that this case points out a fundamental design
disconnect between the C and C++ locales. In C, NUL is not
an ordinary character -- it's a special character that terminates
strings. In addition, C formatted I/O is done in multibyte
characters. In contrast, in C++, NUL is a character like any other
and formatted I/O is always done in single chars (or wchar_t when
char is not wide enough), but never in multibyte characters.
In C, the thousand separator is a multibyte string so even if
grouping is non-empty, inserting an empty string will be as good
as inserting none at all. In C++ the
[jira] Commented: (STDCXX-605) [IBM XLC++] errors compiling dynatype.cpp
[ https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12557880#action_12557880 ] Martin Sebor commented on STDCXX-605: - Travis, after you've confirmed that your change (http://svn.apache.org/viewvc?view=revrevision=610576) fixes the problem in nightly builds we need to remember to merge it to 4.2.1 and update the xfail file: http://svn.apache.org/repos/asf/incubator/stdcxx/trunk/etc/config/xfail.txt [IBM XLC++] errors compiling dynatype.cpp - Key: STDCXX-605 URL: https://issues.apache.org/jira/browse/STDCXX-605 Project: C++ Standard Library Issue Type: Bug Components: Examples Affects Versions: 4.2.0 Environment: XLC++ 6.0 through 9.0/AIX 5.3 Reporter: Martin Sebor Assignee: Travis Vitek Fix For: 4.2.1 Attachments: stdcxx-605-out.patch, stdcxx-605-v1.patch, stdcxx-605-v2.patch, stdcxx-605-v3.patch The dynatype.cpp example program fails to compile with IBM XLC++ 9.0 on AIX with ethe following errors: xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include -I$(BUILDDIR)/include -I$(TOPDIR)/examples/include -O -Q -qtemplateregistry=dynatype.ti $(TOPDIR)/examples/tutorial/dynatype.cpp $(TOPDIR)/examples/tutorial/dynatype.cpp, line 203.27: 1540-0216 (S) An expression of type dynatype cannot be converted to type int. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 209.30: 1540-0216 (S) An expression of type dynatype cannot be converted to type double. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 215.30: 1540-0216 (S) An expression of type dynatype cannot be converted to type double. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 222.35: 1540-0216 (S) An expression of type dynatype cannot be converted to type const char *. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 228.35: 1540-0216 (S) An expression of type dynatype cannot be converted to type const char *. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 238.28: 1540-0216 (S) An expression of type dynatype cannot be converted to type char. gmake: *** [dynatype.o] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-626) [LWG #581] std::ostream::flush() unexpectedly calls to rdbuf()-sync() when rdstate() != goodbit
[ https://issues.apache.org/jira/browse/STDCXX-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-626: Summary: [LWG #581] std::ostream::flush() unexpectedly calls to rdbuf()-sync() when rdstate() != goodbit (was: [LWG #581] std::basic_ostreamchar::flush() unexpectedly calls to rdbuf()-sync() when rdstate() != goodbit) Abbreviated Summary. [LWG #581] std::ostream::flush() unexpectedly calls to rdbuf()-sync() when rdstate() != goodbit - Key: STDCXX-626 URL: https://issues.apache.org/jira/browse/STDCXX-626 Project: C++ Standard Library Issue Type: Bug Components: 27. Input/Output Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 Environment: All Reporter: Farid Zaripov Priority: Trivial Fix For: 4.2.1 The details are here: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#581 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-693) std::valarray::sum does not work correctly for udt that has nonzero default value
[
https://issues.apache.org/jira/browse/STDCXX-693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12557908#action_12557908
]
Martin Sebor commented on STDCXX-693:
-
I agree that the wording in the standard does require it, although I suspect
this interpretation was not intended (I could be wrong). GNU libstdc++ behaves
the same as stdcxx, but STLport does what you expect. The straightforward fix
is to copy the first element to the accumulator:
Index: include/valarray
===
--- include/valarray(revision 609201)
+++ include/valarray(working copy)
@@ -174,7 +174,7 @@
// 26.3.2.7, p2
value_type sum () const {
-return accumulate (_C_array.begin (), _C_array.end (), value_type ());
+return accumulate (_C_array.begin () + 1, _C_array.end (), _C_array
[0]);
}
// 26.3.2.7, p3
Rather than implementing it, I would like to replace the use of
std::accumulate() with a simple loop like so:
Index: include/valarray
===
--- include/valarray(revision 609201)
+++ include/valarray(working copy)
@@ -173,9 +173,7 @@
}
// 26.3.2.7, p2
-value_type sum () const {
-return accumulate (_C_array.begin (), _C_array.end (), value_type ());
-}
+value_type sum () const;
// 26.3.2.7, p3
value_type (min)() const {
Index: include/valarray.cc
===
--- include/valarray.cc (revision 609201)
+++ include/valarray.cc (working copy)
@@ -31,6 +31,18 @@
template class _TypeT
+_TypeT valarray_TypeT::sum () const
+{
+_TypeT __sum (_C_array [0]);
+
+for (_RWSTD_SIZE_T __i = 1; __i _C_array.size (); ++__i)
+__sum += _C_array [__i];
+
+return __sum;
+}
+
+
+template class _TypeT
std::valarray::sum does not work correctly for udt that has nonzero default
value
-
Key: STDCXX-693
URL: https://issues.apache.org/jira/browse/STDCXX-693
Project: C++ Standard Library
Issue Type: Bug
Components: 26. Numerics
Affects Versions: 4.2.0
Reporter: Travis Vitek
Priority: Minor
#include cassert
#include valarray
struct S
{
// this ctor should not be required
S ()
: value (21)
{
}
S (int v)
: value (v)
{
}
S (const S rhs)
: value (rhs.value)
{
}
S operator+= (const S rhs)
{
value += rhs.value;
return *this;
}
int value;
};
int main ()
{
const std::valarrayS b (S (10), 1); // 10 elements with value 1
assert (b.sum ().value == 10);
return 0;
}
The wording in the standard seems to imply that the returned value should be
a copy of one of the elements, and that op+= should be called on all of the
other elements. If this is the case, then this an additional issue that would
be detectable in user code [the user can count how many times the op+= is
invoked]. This issue may apply to the min() and max() methods as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-690) [LWG #198] std::reverse_iterator::operator*() invalidates cached values
[LWG #198] std::reverse_iterator::operator*() invalidates cached values
---
Key: STDCXX-690
URL: https://issues.apache.org/jira/browse/STDCXX-690
Project: C++ Standard Library
Issue Type: Bug
Components: 24. Iterators
Affects Versions: 4.2.0, 4.1.4, 4.1.3, 4.1.2
Reporter: Martin Sebor
According to LWG issue 198
(http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#198), the
implementation of reverse_iterator::operator*() should cache the base
iterator to prevent dangling references to values cached by it. The test case
below demonstrates the problem caused by not doing so:
$ cat t.cpp make t ./t
#include cassert
#include iterator
struct Iterator: std::iteratorstd::random_access_iterator_tag, int
{
int *cur;
int cache;
Iterator (int *p = 0): cur (p) { }
~Iterator () { cache = ~cache; }
reference operator*() { return cache; }
Iterator operator++() { cache = *++cur; return *this; }
Iterator operator--() { cache = *--cur; return *this; }
};
int main ()
{
int a[] = { 1, 2, 3 };
Iterator it (a + sizeof a / sizeof *a);
std::reverse_iteratorIterator rit (it);
const int ref = *rit;
const int val = ref;
++rit;
assert (val == ref);
}
gcc -c -I/home/sebor/stdcxx/include/ansi -D_RWSTDDEBUG -pthread
-I/home/sebor/stdcxx/include -I/build/sebor/stdcxx-gcc-4.1.2-15D/include
-I/home/sebor/stdcxx/examples/include -pedantic -nostdinc++ -g -W -Wall
-Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align
t.cpp
gcc t.o -o t -pthread -L/build/sebor/stdcxx-gcc-4.1.2-15D/lib
-Wl,-R/build/sebor/stdcxx-gcc-4.1.2-15D/lib -lstd15D -lsupc++ -lm
t: t.cpp:29: int main(): Assertion `val == ref' failed.
Aborted
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-690) [LWG #198] std::reverse_iterator::operator*() invalidates cached values
[
https://issues.apache.org/jira/browse/STDCXX-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12557043#action_12557043
]
Martin Sebor commented on STDCXX-690:
-
I think the issue is bogus and should be reverted. See my post below for
details:
Original Message
Subject: Re: effects of reverse_iterator::operator*() and operator-()
Date: Tue, 08 Jan 2008 13:47:15 -0700
From: Martin Sebor [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Organization: Rogue Wave Software, Inc.
To: undisclosed-recipients:;
References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL
PROTECTED]
To: C++ libraries mailing list
Message c++std-lib-19976
I think there's a fundamental problem with issue 198. It acknowledges
that the standard assumes that pointers and references obtained from
an iterator are still valid after iterator destruction or change
while at the same time trying to improve reverse_iterator to make it
work with iterators that violate this assumption by caching the last
dereferenced value and invalidating it after a change to the iterator.
The solution of assigning the value of current to a member variable
with the intent of preserving the last value the iterator might have
cached, will in all likelihood overwrite the previously cached value,
and thus effectively invalidate references to elements previously
read from the sequence. I.e., the solution doesn't guarantee that
references to objects obtained from a reverse_iterator remain valid
until throughout the lifetime of the iterator since incrementing or
decrementing the iterator might still invalidate references obtained
from it.
Since apparently no implementation has adopted the resolution of
issue 198 yet and the solution doesn't go far enough I suggest we
revert to the original text and document this as a limitation of
reverse_iterators.
Martin
A test case that demonstrates the problem is below.
#include cassert
#include iterator
struct Iterator: std::iteratorstd::random_access_iterator_tag, int
{
int *cur;
int cache;
Iterator (int *p = 0): cur (p) { }
~Iterator () { cache = ~cache; }
reference operator*() { return cache; }
Iterator operator++() { cache = *++cur; return *this; }
Iterator operator--() { cache = *--cur; return *this; }
};
int main ()
{
int a[] = { 1, 2, 3 };
Iterator it (a + sizeof a / sizeof *a);
std::reverse_iteratorIterator rit (it);
const int ref = *rit;
const int val = ref;
++rit; *rit;
assert (val == ref); // holds with LWG #198 implemented
++rit; *rit;
assert (val == ref); // fails even with LWG #198
}
[LWG #198] std::reverse_iterator::operator*() invalidates cached values
---
Key: STDCXX-690
URL: https://issues.apache.org/jira/browse/STDCXX-690
Project: C++ Standard Library
Issue Type: Bug
Components: 24. Iterators
Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0
Reporter: Martin Sebor
According to LWG issue 198
(http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#198), the
implementation of reverse_iterator::operator*() should cache the base
iterator to prevent dangling references to values cached by it. The test case
below demonstrates the problem caused by not doing so:
$ cat t.cpp make t ./t
#include cassert
#include iterator
struct Iterator: std::iteratorstd::random_access_iterator_tag, int
{
int *cur;
int cache;
Iterator (int *p = 0): cur (p) { }
~Iterator () { cache = ~cache; }
reference operator*() { return cache; }
Iterator operator++() { cache = *++cur; return *this; }
Iterator operator--() { cache = *--cur; return *this; }
};
int main ()
{
int a[] = { 1, 2, 3 };
Iterator it (a + sizeof a / sizeof *a);
std::reverse_iteratorIterator rit (it);
const int ref = *rit;
const int val = ref;
++rit;
assert (val == ref);
}
gcc -c -I/home/sebor/stdcxx/include/ansi -D_RWSTDDEBUG -pthread
-I/home/sebor/stdcxx/include -I/build/sebor/stdcxx-gcc-4.1.2-15D/include
-I/home/sebor/stdcxx/examples/include -pedantic -nostdinc++ -g -W -Wall
-Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align
t.cpp
gcc t.o -o t -pthread -L/build/sebor/stdcxx-gcc-4.1.2-15D/lib
-Wl,-R/build/sebor/stdcxx-gcc-4.1.2-15D/lib -lstd15D -lsupc++ -lm
t: t.cpp:29: int main(): Assertion `val == ref' failed.
Aborted
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-612) many iterator types do not work with types that implement unary operator
[
https://issues.apache.org/jira/browse/STDCXX-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556720#action_12556720
]
Martin Sebor commented on STDCXX-612:
-
We need to be careful here. We can't change [revers.iter.opref] or any other
function that deliberately relies on the return type of operator() being
[convertible to] pointer.
As for where things should be defined: _defs.h is for macro definitions only.
There shouldn't be any other definitions (types, templates, or functions). As
an aside, we should be using C++ casts in favor of the C-style ones.
Here's how I'd like to propose we proceed:
1) First, to simplify things, eliminate the _RWSTD_ARROW() macro. It's a
workaround for a compiler limitation that none of our compilers suffers from
anymore (check the generated config headers) and so this is a forward
compatible change.
2) For standard container iterators define operator-() in terms of the pointer
data member as opposed to in terms of operator() and avoid having to deal with
any conversion issues.
3) Leave reverse_iterator::operator-() unchanged (i.e., return operator*()).
4) Change istream_iterator::operator-() to simply return _C_val.
5) Change __rw_debug_iter::operator-() to simply return _C_iter.
6) Discuss how to deal with the uninitialized_xxx() algorithms.
many iterator types do not work with types that implement unary operator
-
Key: STDCXX-612
URL: https://issues.apache.org/jira/browse/STDCXX-612
Project: C++ Standard Library
Issue Type: Bug
Components: 24. Iterators
Affects Versions: 4.2.0
Reporter: Travis Vitek
Assignee: Farid Zaripov
Fix For: 4.2.1
Attachments: operator_arrow.patch
Code that uses the macro _RWSTD_OPERATOR_ARROW will be affected by this
issue. Code that has '*' is also very likely to be affected.
#include deque
#include iterator
#include list
#include set
#include vector
struct S
{
void operator () const {};
};
int main ()
{
// this is just a compile test, it is not intended to run
std::reverse_iteratorS*().operator-();
std::setS::iterator().operator-();
std::dequeS::iterator().operator-();
std::listS::iterator().operator-();
return 0;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-605) [IBM XLC++] errors compiling dynatype.cpp
[ https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556723#action_12556723 ] Martin Sebor commented on STDCXX-605: - Do you want to try to commit it now that you have commit privs? [IBM XLC++] errors compiling dynatype.cpp - Key: STDCXX-605 URL: https://issues.apache.org/jira/browse/STDCXX-605 Project: C++ Standard Library Issue Type: Bug Components: Examples Affects Versions: 4.2.0 Environment: XLC++ 6.0 through 9.0/AIX 5.3 Reporter: Martin Sebor Assignee: Travis Vitek Fix For: 4.2.1 Attachments: stdcxx-605-out.patch, stdcxx-605-v1.patch, stdcxx-605-v2.patch, stdcxx-605-v3.patch The dynatype.cpp example program fails to compile with IBM XLC++ 9.0 on AIX with ethe following errors: xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include -I$(BUILDDIR)/include -I$(TOPDIR)/examples/include -O -Q -qtemplateregistry=dynatype.ti $(TOPDIR)/examples/tutorial/dynatype.cpp $(TOPDIR)/examples/tutorial/dynatype.cpp, line 203.27: 1540-0216 (S) An expression of type dynatype cannot be converted to type int. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 209.30: 1540-0216 (S) An expression of type dynatype cannot be converted to type double. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 215.30: 1540-0216 (S) An expression of type dynatype cannot be converted to type double. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 222.35: 1540-0216 (S) An expression of type dynatype cannot be converted to type const char *. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 228.35: 1540-0216 (S) An expression of type dynatype cannot be converted to type const char *. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 238.28: 1540-0216 (S) An expression of type dynatype cannot be converted to type char. gmake: *** [dynatype.o] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-612) many iterator types do not work with types that implement unary operator
[
https://issues.apache.org/jira/browse/STDCXX-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556772#action_12556772
]
Martin Sebor commented on STDCXX-612:
-
I also have no problem deferring this issue for 4.3. It's very much a corner
case. Let's see what Farid thinks about it.
As for compatibility, the [still informal] binary compatibility policy is
silent on this point but I don't think we need to be concerned with
hypothetical compilers when it comes to maintaining compatibility. IMO, we
should only be constrained by compilers we do test and support.
many iterator types do not work with types that implement unary operator
-
Key: STDCXX-612
URL: https://issues.apache.org/jira/browse/STDCXX-612
Project: C++ Standard Library
Issue Type: Bug
Components: 24. Iterators
Affects Versions: 4.2.0
Reporter: Travis Vitek
Assignee: Farid Zaripov
Fix For: 4.2.1
Attachments: operator_arrow.patch
Code that uses the macro _RWSTD_OPERATOR_ARROW will be affected by this
issue. Code that has '*' is also very likely to be affected.
#include deque
#include iterator
#include list
#include set
#include vector
struct S
{
void operator () const {};
};
int main ()
{
// this is just a compile test, it is not intended to run
std::reverse_iteratorS*().operator-();
std::setS::iterator().operator-();
std::dequeS::iterator().operator-();
std::listS::iterator().operator-();
return 0;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-689) [LWG #280] std::reverse_iterator missing template assignment operator
[LWG #280] std::reverse_iterator missing template assignment operator - Key: STDCXX-689 URL: https://issues.apache.org/jira/browse/STDCXX-689 Project: C++ Standard Library Issue Type: Bug Components: 24. Iterators Affects Versions: 4.2.0, 4.1.4, 4.1.3, 4.1.2 Reporter: Martin Sebor Priority: Trivial Fix For: 4.2.1 LWG Issue 280 added a template assignment operator to reverse_iterator: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280 It doesn't look like we ever added the function. I'm having trouble coming up with a test case that would reveal its absence so this is just a placeholder to remind us to look into this in more detail to make sure the function really is needed (if not, there's no need to complicate the interface of the template). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-687) [gcc] use string __builtins
[gcc] use string __builtins --- Key: STDCXX-687 URL: https://issues.apache.org/jira/browse/STDCXX-687 Project: C++ Standard Library Issue Type: Sub-task Affects Versions: 4.2.0, 4.1.4, 4.1.3, 4.1.2 Reporter: Martin Sebor Fix For: 4.2.1 The following gcc builtin equivalents of the C string functions would be useful in the implementation of std::char_traits: __builtin_memcpy: char_traits::copy() __builtin_memcmp: char_traits::compare() __builtin_memmove: char_traits::move() __builtin_memset: char_traits::assign() __builtin_strlen: char_traits::length() Unfortunately, as of gcc 4.2.2, there is no builtin equivalent of memchr() which is used in char_traits::find(), so using the builtins won't let us get away from #including the cstring header to bring in the declaration of the function (thus reducing namespace pollution caused by all the other symbols declared in the header). There also are no builtins for the wide character counterparts of any of these functions (such as wmemcmp or wcslen). See the following page for more details: http://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Other-Builtins.html#Other-Builtins -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-687) [gcc] use string __builtins
[ https://issues.apache.org/jira/browse/STDCXX-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556409#action_12556409 ] Martin Sebor commented on STDCXX-687: - __builtin_memchr was added here: http://gcc.gnu.org/viewcvs?view=revrevision=124617 It can be expected to be included in gcc 4.3. [gcc] use string __builtins --- Key: STDCXX-687 URL: https://issues.apache.org/jira/browse/STDCXX-687 Project: C++ Standard Library Issue Type: Sub-task Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 Reporter: Martin Sebor Fix For: 4.2.1 The following gcc builtin equivalents of the C string functions would be useful in the implementation of std::char_traits: __builtin_memcpy: char_traits::copy() __builtin_memcmp: char_traits::compare() __builtin_memmove: char_traits::move() __builtin_memset: char_traits::assign() __builtin_strlen: char_traits::length() Unfortunately, as of gcc 4.2.2, there is no builtin equivalent of memchr() which is used in char_traits::find(), so using the builtins won't let us get away from #including the cstring header to bring in the declaration of the function (thus reducing namespace pollution caused by all the other symbols declared in the header). There also are no builtins for the wide character counterparts of any of these functions (such as wmemcmp or wcslen). See the following page for more details: http://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Other-Builtins.html#Other-Builtins -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-195) [Linux] error on std::putc()
[
https://issues.apache.org/jira/browse/STDCXX-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Sebor closed STDCXX-195.
---
Resolution: Fixed
Closing as Fixed.
[Linux] error on std::putc()
Key: STDCXX-195
URL: https://issues.apache.org/jira/browse/STDCXX-195
Project: C++ Standard Library
Issue Type: Bug
Components: 27. Input/Output
Affects Versions: 4.1.3
Environment: SuSE SLES 9sp2 (ppc64), IBM XL C/C++ Advanced Edition
V8.0 for Linux
Version: 08.00..
Reporter: Scott (Yu) Zhong
Assignee: Martin Sebor
Fix For: 4.2.1
IBM VAC++ 8.0 linux uses _IO_putc instead of putc
file affected:
include/ansi/cstdio
--- testcase.cpp
#include cstdio
int main()
{
std::putc (test, stdout);
std::fflush (stdout);
}
-- compile line
xlc -F /package/1/ppc64/compilers/ibm/va80/vac.cfg -q64 -qarch=ppc64
-D_RWSTD_NO_IMPLICIT_INCLUSION -qnolib -Wl,-dynamic-linker
-Wl,/lib64/ld64.so.1 -D_RWCONFIG=stdlib_rs -I../../include
-I./../../../../include -I./../../../../include/ansi -I./../../../.. -I.. -I.
-g -c ../testcase.cpp
-- output --
../testcase.cpp, line 5.9: 1540-0130 (S) std::_IO_putc is not declared.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-674) improve GNUmakefile.cfg to scan #included files for dependencies
[ https://issues.apache.org/jira/browse/STDCXX-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-674: Summary: improve GNUmakefile.cfg to scan #included files for dependencies (was: Improve configure script to lookup the dependencies through the all included headers) Corrected grammar in Summary. improve GNUmakefile.cfg to scan #included files for dependencies Key: STDCXX-674 URL: https://issues.apache.org/jira/browse/STDCXX-674 Project: C++ Standard Library Issue Type: Improvement Components: Configuration Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 Environment: All Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Minor Fix For: 4.3 The addition information here: http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg06170.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-430) building Boost with stdcxx
[ https://issues.apache.org/jira/browse/STDCXX-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12555608#action_12555608 ] Martin Sebor commented on STDCXX-430: - As noted in the post below, Boost regression test results with stdcxx have been published here: http://beta.boost.org/development/tests/trunk/developer/summary.html http://www.nabble.com/Running-the-boost-regression-tests-with-stdcxx-td14536939.html#a14536939 building Boost with stdcxx -- Key: STDCXX-430 URL: https://issues.apache.org/jira/browse/STDCXX-430 Project: C++ Standard Library Issue Type: Improvement Components: External Affects Versions: 4.2.0 Reporter: Martin Sebor Assignee: Farid Zaripov Priority: Critical Fix For: 4.2.1 Attachments: boost-1.34.1.patch, boost_regress_gcc.zip, boost_regress_sun.zip, boost_regress_win.zip This is a placeholder issue to make it possible and easy to build the Boost libraries on top of stdcxx. Each stdcxx bug revealed by Boost must have an issue. The issue should be linked to this one. Changes contributed to Boost (such as stdcxx .jam files) should be tracked as subtasks of this issue. Each bug in Boost should be filed in the Boost bug tracking database and cross-referenced in comments on this issue. See the following threads for details of the project: http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg02910.html http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03089.html http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03410.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-536) allow thread safety tests to time out without failing
[ https://issues.apache.org/jira/browse/STDCXX-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-536: Severity: Usability Patch Info: [Patch Available] Set Severity to Usability and checked Patch Available. allow thread safety tests to time out without failing - Key: STDCXX-536 URL: https://issues.apache.org/jira/browse/STDCXX-536 Project: C++ Standard Library Issue Type: Improvement Components: Tests Affects Versions: 4.2.0 Reporter: Martin Sebor Assignee: Travis Vitek Fix For: 4.2.1 Attachments: stdcxx-536.patch The newly added thread safety tests (and possibly some of the existing ones) tend to run for a long time, consuming a lot of CPU cycles, and sometimes even failing due to a timeout (currently 300 seconds in nightly builds). It would be useful to provide a mechanism such as a command line option whereby the tests' runtime could be limited without necessarily causing them to fail when the amount of time is exceeded. One way to do it would be for each test to set an alarm in response to this command line option and in handler for the alarm set a flag that each thread would check at each iteration of its loop to see if it should break. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-536) allow thread safety tests to time out without failing
[ https://issues.apache.org/jira/browse/STDCXX-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12555652#action_12555652 ] Martin Sebor commented on STDCXX-536: - I'm not sure where we left this issue. The discussion kind of petered out... Do we want the patch or not? allow thread safety tests to time out without failing - Key: STDCXX-536 URL: https://issues.apache.org/jira/browse/STDCXX-536 Project: C++ Standard Library Issue Type: Improvement Components: Tests Affects Versions: 4.2.0 Reporter: Martin Sebor Assignee: Travis Vitek Fix For: 4.2.1 Attachments: stdcxx-536.patch The newly added thread safety tests (and possibly some of the existing ones) tend to run for a long time, consuming a lot of CPU cycles, and sometimes even failing due to a timeout (currently 300 seconds in nightly builds). It would be useful to provide a mechanism such as a command line option whereby the tests' runtime could be limited without necessarily causing them to fail when the amount of time is exceeded. One way to do it would be for each test to set an alarm in response to this command line option and in handler for the alarm set a flag that each thread would check at each iteration of its loop to see if it should break. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-195) [Linux] error on std::putc()
[
https://issues.apache.org/jira/browse/STDCXX-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12555762#action_12555762
]
Martin Sebor commented on STDCXX-195:
-
Same problem with getc():
$ cat t.cpp make t
#include cstdio
int main()
{
std::putc ('x', stdout);
std::getc (stdin);
}
gcc -c -I/home/sebor/stdcxx/include/ansi -D_RWSTDDEBUG -pthread
-I/home/sebor/stdcxx/include -I/build/sebor/stdcxx-gcc-4.1.2-15D/include
-I/home/sebor/stdcxx/examples/include -pedantic -nostdinc++ -g -W -Wall
-Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align
t.cpp
t.cpp: In function 'int main()':
t.cpp:5: error: '_IO_putc' is not a member of 'std'
t.cpp:6: error: '_IO_getc' is not a member of 'std'
make: *** [t.o] Error 1
[Linux] error on std::putc()
Key: STDCXX-195
URL: https://issues.apache.org/jira/browse/STDCXX-195
Project: C++ Standard Library
Issue Type: Bug
Components: 27. Input/Output
Affects Versions: 4.1.3
Environment: SuSE SLES 9sp2 (ppc64), IBM XL C/C++ Advanced Edition
V8.0 for Linux
Version: 08.00..
Reporter: Scott (Yu) Zhong
Assignee: Martin Sebor
Fix For: 4.2.1
IBM VAC++ 8.0 linux uses _IO_putc instead of putc
file affected:
include/ansi/cstdio
--- testcase.cpp
#include cstdio
int main()
{
std::putc (test, stdout);
std::fflush (stdout);
}
-- compile line
xlc -F /package/1/ppc64/compilers/ibm/va80/vac.cfg -q64 -qarch=ppc64
-D_RWSTD_NO_IMPLICIT_INCLUSION -qnolib -Wl,-dynamic-linker
-Wl,/lib64/ld64.so.1 -D_RWCONFIG=stdlib_rs -I../../include
-I./../../../../include -I./../../../../include/ansi -I./../../../.. -I.. -I.
-g -c ../testcase.cpp
-- output --
../testcase.cpp, line 5.9: 1540-0130 (S) std::_IO_putc is not declared.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-605) [IBM XLC++] errors compiling dynatype.cpp
[ https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-605: Attachment: stdcxx-605-v3.patch What do you think about the modification in the attached patch? [IBM XLC++] errors compiling dynatype.cpp - Key: STDCXX-605 URL: https://issues.apache.org/jira/browse/STDCXX-605 Project: C++ Standard Library Issue Type: Bug Components: Examples Affects Versions: 4.2.0 Environment: XLC++ 6.0 through 9.0/AIX 5.3 Reporter: Martin Sebor Assignee: Travis Vitek Fix For: 4.2.1 Attachments: stdcxx-605-out.patch, stdcxx-605-v1.patch, stdcxx-605-v2.patch, stdcxx-605-v3.patch The dynatype.cpp example program fails to compile with IBM XLC++ 9.0 on AIX with ethe following errors: xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include -I$(BUILDDIR)/include -I$(TOPDIR)/examples/include -O -Q -qtemplateregistry=dynatype.ti $(TOPDIR)/examples/tutorial/dynatype.cpp $(TOPDIR)/examples/tutorial/dynatype.cpp, line 203.27: 1540-0216 (S) An expression of type dynatype cannot be converted to type int. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 209.30: 1540-0216 (S) An expression of type dynatype cannot be converted to type double. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 215.30: 1540-0216 (S) An expression of type dynatype cannot be converted to type double. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 222.35: 1540-0216 (S) An expression of type dynatype cannot be converted to type const char *. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 228.35: 1540-0216 (S) An expression of type dynatype cannot be converted to type const char *. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 238.28: 1540-0216 (S) An expression of type dynatype cannot be converted to type char. gmake: *** [dynatype.o] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-620) purify reports memory leak in 21_nonmembers test
[ https://issues.apache.org/jira/browse/STDCXX-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-620: Patch Info: (was: [Patch Available]) I don't see a patch anywhere... purify reports memory leak in 21_nonmembers test Key: STDCXX-620 URL: https://issues.apache.org/jira/browse/STDCXX-620 Project: C++ Standard Library Issue Type: Bug Components: Test Driver Affects Versions: 4.2.0 Reporter: Travis Vitek Assignee: Travis Vitek Priority: Minor Fix For: 4.2.1 Attachments: 21_nonmembers.log Memory is leaked because a string is being duplicated unnecessarily. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-597) purify reports uninitialized memory read in _rw_get_char
[
https://issues.apache.org/jira/browse/STDCXX-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12555420#action_12555420
]
Martin Sebor commented on STDCXX-597:
-
Travis, I get one assertion from 0.char before applying the patch:
# ASSERTION (S7) (3 lines):
# TEXT: rw_printf(%{/*Gs}, ...) == \\; got (misaligned address
0x0042c8a7)
# LINE: 1142
and 5 after applying it:
# ASSERTION (S7) (3 lines):
# TEXT: rw_match([EMAIL PROTECTED]@0b, ab, 2) == 140733193388034, got 1
# LINE: 819
# ASSERTION (S7) (3 lines):
# TEXT: rw_match([EMAIL PROTECTED]@[EMAIL PROTECTED]@3, [EMAIL
PROTECTED]@[EMAIL PROTECTED]@0, 7) == 140733193388039, got 6
# LINE: 855
# ASSERTION (S7) (3 lines):
# TEXT: rw_match([EMAIL PROTECTED]@0b, Lab, 2) == 140733193388034, got 1
# LINE: 970
# ASSERTION (S7) (3 lines):
# TEXT: rw_match([EMAIL PROTECTED]@0b, ab, 2) == 140733193388034, got 1
# LINE: 1063
# ASSERTION (S7) (3 lines):
# TEXT: rw_printf(%{/*Gs}, ...) == \\; got (misaligned address
0x0042c8c7)
# LINE: 1142
purify reports uninitialized memory read in _rw_get_char
-
Key: STDCXX-597
URL: https://issues.apache.org/jira/browse/STDCXX-597
Project: C++ Standard Library
Issue Type: Improvement
Components: Test Driver
Affects Versions: 4.2.0
Reporter: Travis Vitek
Priority: Minor
Fix For: 4.2.1
Attachments: stdcxx-597.patch
Purify instrumented ./21.string.access (pid 2878)
UMR: Uninitialized memory read:
* This is occurring while in thread 2878:
_rw_get_char(char const*, char const**, unsigned*) [char.cpp:562]
rw_match(char const*, char const*, unsigned) [char.cpp:816]
test_accesschar, std::char_traitschar, std::allocatorchar (char,
std::char_traitschar*, char*, StringFunc const, StringTestCase const)
[21.string.access.cpp:274]
test_access(StringFunc const, StringTestCase const)
[21.string.access.cpp:317]
_rw_test_case(StringFunc const, StringTestCase const, (*)(StringFunc
const, StringTestCase const)) [21.strings.cpp:1298]
_rw_run_cases(StringFunc const, StringTest const) [21.strings.cpp:1353]
* Reading 1 byte from 0x8182256 in the heap.
* Address 0x8182256 is 14 bytes into a malloc'd block at 0x8182248 of 46
bytes.
* This block was allocated from thread -1207973632:
malloc [rtlib.o]
operator new(unsigned) [libstd15d.so]
__rw::__rw_allocate(unsigned, int) [memory.cpp:53]
std::allocatorchar::allocate(unsigned, const*) [_allocator.h:144]
std::stringchar, std::char_traitschar,
std::allocatorchar::_C_get_rep(unsigned, unsigned) [string.cc:102]
std::stringchar, std::char_traitschar,
std::allocatorchar::stringchar, std::char_traitschar,
std::allocatorchar[not-in-charge](char const*, unsigned,
std::allocatorchar const) [string.cc:180]
Purify instrumented ./21.string.access (pid 2878)
UMR: Uninitialized memory read:
* This is occurring while in thread 2878:
_rw_get_char(char const*, char const**, unsigned*) [char.cpp:562]
rw_match(char const*, char const*, unsigned) [char.cpp:816]
test_accesschar, UserTraitschar, std::allocatorchar (char,
UserTraitschar*, char*, StringFunc const, StringTestCase const)
[21.string.access.cpp:274]
test_access(StringFunc const, StringTestCase const)
[21.string.access.cpp:317]
_rw_test_case(StringFunc const, StringTestCase const, (*)(StringFunc
const, StringTestCase const)) [21.strings.cpp:1298]
_rw_run_cases(StringFunc const, StringTest const) [21.strings.cpp:1353]
* Reading 1 byte from 0x818d5a6 in the heap.
* Address 0x818d5a6 is 14 bytes into a malloc'd block at 0x818d598 of 46
bytes.
* This block was allocated from thread -1207973632:
malloc [rtlib.o]
operator new(unsigned) [libstd15d.so]
__rw::__rw_allocate(unsigned, int) [memory.cpp:53]
std::allocatorchar::allocate(unsigned, const*) [_allocator.h:144]
std::basic_stringchar, std::char_traitschar,
std::allocatorcharchar, UserTraitschar, std::allocatorchar
::_C_get_rep(unsigned, unsigned) [string.cc:102]
std::basic_stringchar, std::char_traitschar,
std::allocatorcharchar, UserTraitschar, std::allocatorchar
::basic_stringchar, std::char_traitschar,
std::allocatorchar[not-in-charge](char const*, unsigned,
std::allocatorchar const) [string.cc:180]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-577) purify reports leaked memory in stocks example
[ https://issues.apache.org/jira/browse/STDCXX-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-577: Attachment: stocks-valgrind.log Btw., I get the attached leaks from valgrind on Linux (11S) even after applying the patch. Is Purify output clean in this build type? purify reports leaked memory in stocks example --- Key: STDCXX-577 URL: https://issues.apache.org/jira/browse/STDCXX-577 Project: C++ Standard Library Issue Type: Improvement Components: Examples Affects Versions: 4.2.0 Reporter: Travis Vitek Assignee: Travis Vitek Fix For: 4.2.1 Attachments: stdcxx-577.patch, stocks-valgrind.log, stocks.log It is pretty obvious from looking at the source that memory is being leaked. The destructor for StockXchange doesn't deallocate memory allocated in StockXchange::add(), and the sl_pairs allocated in main are never deallocated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-685) [Windows] slashes in Windows pathnames in build logs
[Windows] slashes in Windows pathnames in build logs Key: STDCXX-685 URL: https://issues.apache.org/jira/browse/STDCXX-685 Project: C++ Standard Library Issue Type: Bug Components: Build Affects Versions: 4.2.0 Reporter: Martin Sebor Assignee: Farid Zaripov Priority: Trivial The Windows build logs are mixing slashes and backclashes in pathnames when linking library objects (see below). We should be consistent and use the same path separator everywhere. Build started: Project: .stdcxx, Configuration: 8s Optimized Static|Win32 ... Creating command line cmd.exe /c C:\DOCUME~1\batman\LOCALS~1\Temp\VadA21F.bat Creating temporary file C:\DOCUME~1\batman\LOCALS~1\Temp\RSPA222.bs with contents [ /c /O2 /I $(TOPDIR)\include /I $(TOPDIR)\include\ansi /I $(BUILDDIR)\8s\include /D _MBCS /FD /EHsc /MT /GS- /GR /Fo$(BUILDDIR)\8s\src/ /W3 /nologo /Zi /Gd /D_CRT_SECURE_NO_DEPRECATE /Qvc8 /Qlocation,link,C:\Program Files\Microsoft Visual Studio 8\VC\bin ..\..\..\src\strtol.cpp ..\..\..\src\ti_time_get.cpp ..\..\..\src\locale_global.cpp ... ] Creating command line icl.exe @C:\DOCUME~1\batman\LOCALS~1\Temp\RSPA222.bs Creating temporary file C:\DOCUME~1\batman\LOCALS~1\Temp\RSPA225.bs with contents [ /OUT:$(BUILDDIR)\8s\lib\libstd8s.lib /nologo /NODEFAULTLIB:libcpmt.lib $(BUILDDIR)\8s\src/assert.obj $(BUILDDIR)\8s\src\atomic.obj $(BUILDDIR)\8s\src/bitset.obj $(BUILDDIR)\8s\src/catalog.obj ... $(BUILDDIR)\8s\src/version.obj $(BUILDDIR)\8s\src/wcodecvt.obj $(BUILDDIR)\8s\src/wctype.obj ] Creating command line xilib.exe @C:\DOCUME~1\batman\LOCALS~1\Temp\RSPA225.bs --- -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-683) implement notion of expected failures in the test suite
[ https://issues.apache.org/jira/browse/STDCXX-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553737 ] Martin Sebor commented on STDCXX-683: - 4) In addition to the requirements listed above, the system itself (as opposed to the user) must indicate when a successful outcome is not expected. I.e., when a component such as a test is expected to fail but succeeds it must be highlighted as such so as to distinguish it from an ordinary success and make it easy to remove the expected failure markup. implement notion of expected failures in the test suite --- Key: STDCXX-683 URL: https://issues.apache.org/jira/browse/STDCXX-683 Project: C++ Standard Library Issue Type: New Feature Components: Test Driver, Tests Affects Versions: 4.2.0 Reporter: Martin Sebor Assignee: Martin Sebor Priority: Critical Attachments: codes.html Tests (or examples) that fail for known reasons that we haven't been able to deal with should be distinguished from failures that haven't been analyzed yet. For example, an example program that fails to compile on an older target platform because of a compiler bug that we can't find a simple/elegant workaround should be flagged as such in the test results. Similarly, a test that fails one or more assertions due to compiler or libc bugs on a specific platform (or a set of platforms) that we are unable to work around should be reported as such. This is important in order to reduce the currently fairly large number of unexpected failures and to be able to make changes without having to worry about regressions as much. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (STDCXX-683) implement notion of expected failures in the test suite
[ https://issues.apache.org/jira/browse/STDCXX-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553737 ] sebor edited comment on STDCXX-683 at 12/20/07 10:05 AM: 4. In addition to the requirements listed above, the system itself (as opposed to the user) must indicate when a successful outcome is not expected. I.e., when a component such as a test is expected to fail but succeeds it must be highlighted as such so as to distinguish it from an ordinary success and make it easy to remove the expected failure markup. was (Author: sebor): 4) In addition to the requirements listed above, the system itself (as opposed to the user) must indicate when a successful outcome is not expected. I.e., when a component such as a test is expected to fail but succeeds it must be highlighted as such so as to distinguish it from an ordinary success and make it easy to remove the expected failure markup. implement notion of expected failures in the test suite --- Key: STDCXX-683 URL: https://issues.apache.org/jira/browse/STDCXX-683 Project: C++ Standard Library Issue Type: New Feature Components: Test Driver, Tests Affects Versions: 4.2.0 Reporter: Martin Sebor Assignee: Martin Sebor Priority: Critical Attachments: codes.html Tests (or examples) that fail for known reasons that we haven't been able to deal with should be distinguished from failures that haven't been analyzed yet. For example, an example program that fails to compile on an older target platform because of a compiler bug that we can't find a simple/elegant workaround should be flagged as such in the test results. Similarly, a test that fails one or more assertions due to compiler or libc bugs on a specific platform (or a set of platforms) that we are unable to work around should be reported as such. This is important in order to reduce the currently fairly large number of unexpected failures and to be able to make changes without having to worry about regressions as much. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-683) implement notion of expected failures in the test suite
[ https://issues.apache.org/jira/browse/STDCXX-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-683: Attachment: (was: xcodes.html) implement notion of expected failures in the test suite --- Key: STDCXX-683 URL: https://issues.apache.org/jira/browse/STDCXX-683 Project: C++ Standard Library Issue Type: New Feature Components: Test Driver, Tests Affects Versions: 4.2.0 Reporter: Martin Sebor Assignee: Martin Sebor Priority: Critical Attachments: codes.html Tests (or examples) that fail for known reasons that we haven't been able to deal with should be distinguished from failures that haven't been analyzed yet. For example, an example program that fails to compile on an older target platform because of a compiler bug that we can't find a simple/elegant workaround should be flagged as such in the test results. Similarly, a test that fails one or more assertions due to compiler or libc bugs on a specific platform (or a set of platforms) that we are unable to work around should be reported as such. This is important in order to reduce the currently fairly large number of unexpected failures and to be able to make changes without having to worry about regressions as much. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-683) implement notion of expected failures in the test suite
[ https://issues.apache.org/jira/browse/STDCXX-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-683: Attachment: xcodes.html Attached an updated set of extended status codes to distinguish not only expected failures from ordinary (unexpected) ones, but also unexpected successes from ordinary (expected) ones. implement notion of expected failures in the test suite --- Key: STDCXX-683 URL: https://issues.apache.org/jira/browse/STDCXX-683 Project: C++ Standard Library Issue Type: New Feature Components: Test Driver, Tests Affects Versions: 4.2.0 Reporter: Martin Sebor Assignee: Martin Sebor Priority: Critical Attachments: codes.html, xcodes.html Tests (or examples) that fail for known reasons that we haven't been able to deal with should be distinguished from failures that haven't been analyzed yet. For example, an example program that fails to compile on an older target platform because of a compiler bug that we can't find a simple/elegant workaround should be flagged as such in the test results. Similarly, a test that fails one or more assertions due to compiler or libc bugs on a specific platform (or a set of platforms) that we are unable to work around should be reported as such. This is important in order to reduce the currently fairly large number of unexpected failures and to be able to make changes without having to worry about regressions as much. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-683) implement notion of expected failures in the test suite
[ https://issues.apache.org/jira/browse/STDCXX-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553812 ] Martin Sebor commented on STDCXX-683: - Requirements on Markups 1. Location. The markups must be in the form of human-readable and editable text stored in a location that can be easily and intuitively associated with each component (currently, example, locale, or test). One obvious location is the source code for each component itself. There, the markups could take the form of comments that could be easily found by the test harness. Another convenient location is a separate file with the same base name but a different suffix than the component itself. Yet another possibility is storing all markups in a single text file and with the name of the component as the key. The implementation should be such so as to make it easy to switch from one location to the next if it turns out to be convenient. 2. Format. The format of the markups must be easy to read and write and make it possible to easily express precise constraints involving the operating system and its version, the compiler and its version, the library configuration, and the expected status. It must be possible to set more than one constraint for each component, and it must be possible for a single constraint to refer to more than one platform or configuration. One possible format is to use relational operators and boolean logic. For example, to refer to XLC++ 7.0.0.9 on AIX 5.3 and prior, the expression might look something like this: os==AIX (os_major5 || os_major==5 os_minor=3) compiler==XLC compiler_major==7 compiler_minor==0 compiler_micro==0 compiler_patch==9. Another possible format is to adopt a conveniton similar to the GNU cpu-vendor-os triple produced by config.guess (an example of such a triple is i386-redhat-linux or sparc-sun-solaris2.9). In our case, the GNU convention would need to be modified and extended to include the compiler and the library configuration and might look something like this: cpu-vendor-os-compiler-configuration. We could then use shell globbing to implement matching. For example, the following two patterns would have to be used at the same time in order to refer to a 15D configuration of the library build with XLC++ 7.0.0.9 on AIX 5.3 and prior: *-ibm-aix5.[0-3]-xlc7.0.0.9-15D *-ibm-aix[1-4].*-xlc7.0.0.9-15D The leading asterisk indicates no preference for the CPU component. implement notion of expected failures in the test suite --- Key: STDCXX-683 URL: https://issues.apache.org/jira/browse/STDCXX-683 Project: C++ Standard Library Issue Type: New Feature Components: Test Driver, Tests Affects Versions: 4.2.0 Reporter: Martin Sebor Assignee: Martin Sebor Priority: Critical Attachments: codes.html, xcodes.html Tests (or examples) that fail for known reasons that we haven't been able to deal with should be distinguished from failures that haven't been analyzed yet. For example, an example program that fails to compile on an older target platform because of a compiler bug that we can't find a simple/elegant workaround should be flagged as such in the test results. Similarly, a test that fails one or more assertions due to compiler or libc bugs on a specific platform (or a set of platforms) that we are unable to work around should be reported as such. This is important in order to reduce the currently fairly large number of unexpected failures and to be able to make changes without having to worry about regressions as much. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-683) implement notion of expected failures in the test suite
[ https://issues.apache.org/jira/browse/STDCXX-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553857 ] Martin Sebor commented on STDCXX-683: - I left these out on purpose, but on second thought I agree that XFMAT should be added. I don't think XNOUT makes sense because NOUT is an expected state for regression tests and would unexpected for any other kind. implement notion of expected failures in the test suite --- Key: STDCXX-683 URL: https://issues.apache.org/jira/browse/STDCXX-683 Project: C++ Standard Library Issue Type: New Feature Components: Test Driver, Tests Affects Versions: 4.2.0 Reporter: Martin Sebor Assignee: Martin Sebor Priority: Critical Attachments: codes.html, xcodes.html Tests (or examples) that fail for known reasons that we haven't been able to deal with should be distinguished from failures that haven't been analyzed yet. For example, an example program that fails to compile on an older target platform because of a compiler bug that we can't find a simple/elegant workaround should be flagged as such in the test results. Similarly, a test that fails one or more assertions due to compiler or libc bugs on a specific platform (or a set of platforms) that we are unable to work around should be reported as such. This is important in order to reduce the currently fairly large number of unexpected failures and to be able to make changes without having to worry about regressions as much. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (STDCXX-683) implement notion of expected failures in the test suite
[ https://issues.apache.org/jira/browse/STDCXX-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553857 ] sebor edited comment on STDCXX-683 at 12/20/07 9:25 PM: --- I left these out on purpose, but on second thought I agree that XFMAT should be added. I don't think XNOUT makes sense because NOUT is an expected state for regression tests and would be unexpected for any other kind. was (Author: sebor): I left these out on purpose, but on second thought I agree that XFMAT should be added. I don't think XNOUT makes sense because NOUT is an expected state for regression tests and would unexpected for any other kind. implement notion of expected failures in the test suite --- Key: STDCXX-683 URL: https://issues.apache.org/jira/browse/STDCXX-683 Project: C++ Standard Library Issue Type: New Feature Components: Test Driver, Tests Affects Versions: 4.2.0 Reporter: Martin Sebor Assignee: Martin Sebor Priority: Critical Attachments: codes.html, xcodes.html Tests (or examples) that fail for known reasons that we haven't been able to deal with should be distinguished from failures that haven't been analyzed yet. For example, an example program that fails to compile on an older target platform because of a compiler bug that we can't find a simple/elegant workaround should be flagged as such in the test results. Similarly, a test that fails one or more assertions due to compiler or libc bugs on a specific platform (or a set of platforms) that we are unable to work around should be reported as such. This is important in order to reduce the currently fairly large number of unexpected failures and to be able to make changes without having to worry about regressions as much. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-585) [gcc 4.2.0/Cygwin] linker errors due to multiple definition of `std::bad_cast::what()'; `std::bad_typeid::what()'; `std::bad_exception::what()'; `std::bad_alloc::what()'
[ https://issues.apache.org/jira/browse/STDCXX-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553391 ] Martin Sebor commented on STDCXX-585: - FWIW, I would have preferred to commit this on trunk only and wait for a full set of results before merging it out to 4.2.1. [gcc 4.2.0/Cygwin] linker errors due to multiple definition of `std::bad_cast::what()'; `std::bad_typeid::what()'; `std::bad_exception::what()'; `std::bad_alloc::what()' - Key: STDCXX-585 URL: https://issues.apache.org/jira/browse/STDCXX-585 Project: C++ Standard Library Issue Type: Bug Components: Configuration Affects Versions: 4.2.0 Environment: gcc 4.2.0 / Cygwin Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Blocker Fix For: 4.2.1 Attachments: BAD_ALLOC_ASSIGNMENT.cpp.diff When building the stdcxx on Cygwin I get errors like: make: Entering directory `/usr/src/stdcxx/trunk/build/examples' gcc -c -I/usr/src/stdcxx/trunk/include/ansi -D_RWSTDDEBUG -D_REENTRANT -mthreads -I/usr/src/stdcxx/trunk/include -I/usr/src/stdcxx/trunk/build/include -I/usr/src/stdcxx/trunk/examples/include -pedantic -nostdinc++ -g -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align /usr/src/stdcxx/trunk/examples/manual/accumulate.cpp gcc accumulate.o -o accumulate -mthreads -L/usr/src/stdcxx/trunk/build/lib -lstd15s -lsupc++ -lcatgets -liconv -lm /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(tinfo.o): In function `_ZNK10__cxxabiv121__vmi_class_type_info12__do_dyncastEiNS_17__class_type_info10__sub_kindEPKS1_PKvS4_S6_RNS1_16__dyncast_resultE': /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/tinfo.cc:418: multiple definition of `std::bad_cast::what() const' /usr/src/stdcxx/trunk/build/lib/libstd15s.a(typeinfo.o):/usr/src/stdcxx/trunk/src/typeinfo.cpp:349: first defined here /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(tinfo.o): In function `_ZNK10__cxxabiv121__vmi_class_type_info12__do_dyncastEiNS_17__class_type_info10__sub_kindEPKS1_PKvS4_S6_RNS1_16__dyncast_resultE': /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/tinfo.cc:418: multiple definition of `std::bad_typeid::what() const' /usr/src/stdcxx/trunk/build/lib/libstd15s.a(typeinfo.o):/usr/src/stdcxx/trunk/src/typeinfo.cpp:414: first defined here /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(new_handler.o): In function `_ZNSt9bad_allocD2Ev': /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/new_handler.cc:48: multiple definition of `std::bad_alloc::what() const' /usr/src/stdcxx/trunk/build/lib/libstd15s.a(memory.o):/usr/src/stdcxx/trunk/src/memory.cpp:331: first defined here /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(eh_exception.o): In function `_ZNSt13bad_exceptionD2Ev': /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/eh_exception.cc:38: multiple definition of `std::bad_exception::what() const' /usr/src/stdcxx/trunk/build/lib/libstd15s.a(exception.o):/usr/src/stdcxx/trunk/src/exception.cpp:412: first defined here collect2: ld returned 1 exit status make: *** [accumulate] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-683) implement notion of expected failures in the test suite
[ https://issues.apache.org/jira/browse/STDCXX-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor reassigned STDCXX-683: --- Assignee: Martin Sebor implement notion of expected failures in the test suite --- Key: STDCXX-683 URL: https://issues.apache.org/jira/browse/STDCXX-683 Project: C++ Standard Library Issue Type: New Feature Components: Test Driver, Tests Affects Versions: 4.2.0 Reporter: Martin Sebor Assignee: Martin Sebor Priority: Critical Tests (or examples) that fail for known reasons that we haven't been able to deal with should be distinguished from failures that haven't been analyzed yet. For example, an example program that fails to compile on an older target platform because of a compiler bug that we can't find a simple/elegant workaround should be flagged as such in the test results. Similarly, a test that fails one or more assertions due to compiler or libc bugs on a specific platform (or a set of platforms) that we are unable to work around should be reported as such. This is important in order to reduce the currently fairly large number of unexpected failures and to be able to make changes without having to worry about regressions as much. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-683) implement notion of expected failures in the test suite
[ https://issues.apache.org/jira/browse/STDCXX-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-683: Attachment: codes.html Attached the current set of status codes used to report test results. Implementing the expected failures enhancement will mean extending the set of codes to distinguish ordinary (unexpected) failures from the expected ones. implement notion of expected failures in the test suite --- Key: STDCXX-683 URL: https://issues.apache.org/jira/browse/STDCXX-683 Project: C++ Standard Library Issue Type: New Feature Components: Test Driver, Tests Affects Versions: 4.2.0 Reporter: Martin Sebor Assignee: Martin Sebor Priority: Critical Attachments: codes.html Tests (or examples) that fail for known reasons that we haven't been able to deal with should be distinguished from failures that haven't been analyzed yet. For example, an example program that fails to compile on an older target platform because of a compiler bug that we can't find a simple/elegant workaround should be flagged as such in the test results. Similarly, a test that fails one or more assertions due to compiler or libc bugs on a specific platform (or a set of platforms) that we are unable to work around should be reported as such. This is important in order to reduce the currently fairly large number of unexpected failures and to be able to make changes without having to worry about regressions as much. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-683) implement notion of expected failures in the test suite
[ https://issues.apache.org/jira/browse/STDCXX-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-683: Attachment: codes.html Attached a proposed set of extended status codes to distinguish expected failures from ordinary (unexpected) ones. implement notion of expected failures in the test suite --- Key: STDCXX-683 URL: https://issues.apache.org/jira/browse/STDCXX-683 Project: C++ Standard Library Issue Type: New Feature Components: Test Driver, Tests Affects Versions: 4.2.0 Reporter: Martin Sebor Assignee: Martin Sebor Priority: Critical Attachments: codes.html, codes.html Tests (or examples) that fail for known reasons that we haven't been able to deal with should be distinguished from failures that haven't been analyzed yet. For example, an example program that fails to compile on an older target platform because of a compiler bug that we can't find a simple/elegant workaround should be flagged as such in the test results. Similarly, a test that fails one or more assertions due to compiler or libc bugs on a specific platform (or a set of platforms) that we are unable to work around should be reported as such. This is important in order to reduce the currently fairly large number of unexpected failures and to be able to make changes without having to worry about regressions as much. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-683) implement notion of expected failures in the test suite
[ https://issues.apache.org/jira/browse/STDCXX-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-683: Attachment: (was: codes.html) implement notion of expected failures in the test suite --- Key: STDCXX-683 URL: https://issues.apache.org/jira/browse/STDCXX-683 Project: C++ Standard Library Issue Type: New Feature Components: Test Driver, Tests Affects Versions: 4.2.0 Reporter: Martin Sebor Assignee: Martin Sebor Priority: Critical Attachments: codes.html, xcodes.html Tests (or examples) that fail for known reasons that we haven't been able to deal with should be distinguished from failures that haven't been analyzed yet. For example, an example program that fails to compile on an older target platform because of a compiler bug that we can't find a simple/elegant workaround should be flagged as such in the test results. Similarly, a test that fails one or more assertions due to compiler or libc bugs on a specific platform (or a set of platforms) that we are unable to work around should be reported as such. This is important in order to reduce the currently fairly large number of unexpected failures and to be able to make changes without having to worry about regressions as much. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-683) implement notion of expected failures in the test suite
[ https://issues.apache.org/jira/browse/STDCXX-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-683: Attachment: xcodes.html This time really attached the proposed set of extended status codes to distinguish expected failures from ordinary (unexpected) ones. implement notion of expected failures in the test suite --- Key: STDCXX-683 URL: https://issues.apache.org/jira/browse/STDCXX-683 Project: C++ Standard Library Issue Type: New Feature Components: Test Driver, Tests Affects Versions: 4.2.0 Reporter: Martin Sebor Assignee: Martin Sebor Priority: Critical Attachments: codes.html, xcodes.html Tests (or examples) that fail for known reasons that we haven't been able to deal with should be distinguished from failures that haven't been analyzed yet. For example, an example program that fails to compile on an older target platform because of a compiler bug that we can't find a simple/elegant workaround should be flagged as such in the test results. Similarly, a test that fails one or more assertions due to compiler or libc bugs on a specific platform (or a set of platforms) that we are unable to work around should be reported as such. This is important in order to reduce the currently fairly large number of unexpected failures and to be able to make changes without having to worry about regressions as much. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-683) implement notion of expected failures in the test suite
[ https://issues.apache.org/jira/browse/STDCXX-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553567 ] Martin Sebor commented on STDCXX-683: - Travis and I discussed this enhancement a few weeks back and here are the main goals we came up with: 1. It must be possible to mark up any failure in any component of the build and test process (i.e., any example, locale, or test) as an expected failure. This includes failure to compile, failure to link, exiting with a signal, exiting with a non-zero status, failure to produce the expected output (i.e., the DIFF status for examples), and individual failed assertions (in tests). 2. For each such markup/failure, it must be possible to differentiate between the same set of platforms and configurations of the library that are distinguished by the current build and test reporting system. That a mechanism must be provided to make it possible to specify that a particular failure (for example, a failure to compile) is expected to occur only on a specific platform (e.g., with IBM XLC++ 7.0.0.9 on AIX 5.3) or a set of platforms (e.g., with all versions of gcc prior to 3.2.4, or with any compiler on Solaris), and only in a particular configuration of the library (such as 12D, or optimized, shared, thread-safe, wide or 64-bit) or a set of such configurations (e.g., all 64-bit ones). 3. For tests, it must be possible to mark up individual failed assertions (and any other types of diagnostics) as expected using their sequential numbers (assigned to them by the test driver) at runtime. implement notion of expected failures in the test suite --- Key: STDCXX-683 URL: https://issues.apache.org/jira/browse/STDCXX-683 Project: C++ Standard Library Issue Type: New Feature Components: Test Driver, Tests Affects Versions: 4.2.0 Reporter: Martin Sebor Assignee: Martin Sebor Priority: Critical Attachments: codes.html, xcodes.html Tests (or examples) that fail for known reasons that we haven't been able to deal with should be distinguished from failures that haven't been analyzed yet. For example, an example program that fails to compile on an older target platform because of a compiler bug that we can't find a simple/elegant workaround should be flagged as such in the test results. Similarly, a test that fails one or more assertions due to compiler or libc bugs on a specific platform (or a set of platforms) that we are unable to work around should be reported as such. This is important in order to reduce the currently fairly large number of unexpected failures and to be able to make changes without having to worry about regressions as much. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-524) buffer overflow in test 22.locale.time.get.cpp (make_LC_TIME)
[ https://issues.apache.org/jira/browse/STDCXX-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-524: Severity: Runtime Error Summary: buffer overflow in test 22.locale.time.get.cpp (make_LC_TIME) (was: buffer overflow in test 22.locale.time.get.cpp(make_LC_TIME)) Added a missing space. buffer overflow in test 22.locale.time.get.cpp (make_LC_TIME) - Key: STDCXX-524 URL: https://issues.apache.org/jira/browse/STDCXX-524 Project: C++ Standard Library Issue Type: Bug Components: Tests Affects Versions: 4.1.2, 4.1.3, 4.1.4 Reporter: Travis Vitek Assignee: Travis Vitek Priority: Trivial Fix For: 4.2.1 Attachments: stdcxx-524.patch This test uses L_tmpnam to determine the length of a buffer used to store a filename string. Unfortunately, L_tmpnam is intended for use with tmpnam(), but the buffer is written to with std::sprintf(). When I run the test, the allocated buffer is 46 bytes, and the sprintf() call writes 58 bytes [this will vary based on user name and other variables]. Perhaps the buffer should be made larger, or some other method should be used to fill the buffer. Perhaps this would work. #if !defined (_WIN32) !defined (_WIN64) # define _PATH_MAX PATH_MAX #else # define _PATH_MAX _MAX_PATH #endif char srcfname [_PATH_MAX]; // [L_tmpnam + 32]; std::sprintf (srcfname, %s SLASH LC_TIME.src, locale_root); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-682) move build result pages from ~sebor to the stdcxx site
move build result pages from ~sebor to the stdcxx site -- Key: STDCXX-682 URL: https://issues.apache.org/jira/browse/STDCXX-682 Project: C++ Standard Library Issue Type: Task Components: Web Reporter: Martin Sebor The nightly build result pages currently stored in http://people.apache.org/~sebor/ need to be moved to some project-specific directory, such as http://incubator.apache.org/stdcxx/ is now. This should be done after the stdcxx has been moved to its final location as a Top Level Project, i.e., after INFRA-1425 has been resolved. Currently, stdcxx build results for trunk are stored at the following locations: http://people.apache.org/~sebor/stdcxx/results http://people.apache.org/~sebor/stdcxx/results/builds and those for stdcxx-4.2.0 are here: http://people.apache.org/~sebor/stdcxx-4.2.0/results/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-683) implement notion of expected failures in the test suite
implement notion of expected failures in the test suite --- Key: STDCXX-683 URL: https://issues.apache.org/jira/browse/STDCXX-683 Project: C++ Standard Library Issue Type: New Feature Components: Test Driver, Tests Affects Versions: 4.2.0 Reporter: Martin Sebor Priority: Critical Tests (or examples) that fail for known reasons that we haven't been able to deal with should be distinguished from failures that haven't been analyzed yet. For example, an example program that fails to compile on an older target platform because of a compiler bug that we can't find a simple/elegant workaround should be flagged as such in the test results. Similarly, a test that fails one or more assertions due to compiler or libc bugs on a specific platform (or a set of platforms) that we are unable to work around should be reported as such. This is important in order to reduce the currently fairly large number of unexpected failures and to be able to make changes without having to worry about regressions as much. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-684) auto-detect _RWSTD_VER value from branch/file name
[ https://issues.apache.org/jira/browse/STDCXX-684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-684: Summary: auto-detect _RWSTD_VER value from branch/file name (was: ato-detect _RWSTD_VER value from branch/file name) auto-detect _RWSTD_VER value from branch/file name -- Key: STDCXX-684 URL: https://issues.apache.org/jira/browse/STDCXX-684 Project: C++ Standard Library Issue Type: New Feature Components: Configuration Affects Versions: 4.2.0 Reporter: Martin Sebor Priority: Minor As suggested in the thread below, it would be useful to a) guarantee that the value of the _RWSTD_VER macro is unique to each branch and trunk, and b) to let the library configuration infrastructure automatically figure out the value from the name of the branch the file came from, e.g., by manipulating the value of the $HeadURL$ Subversion keyword. http://www.nabble.com/Re-3A-svn-commit-3A-r597396incubator-stdcxx-branches-4.2.x-tests-numerics-26.valarray.cassign.cpp-to13905517.html#a14289920 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-459) time_get::date_order() should return actually date order taken from locale
[ https://issues.apache.org/jira/browse/STDCXX-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551846 ] Martin Sebor commented on STDCXX-459: - The patch looks good to me in general but I have a few compatibility concerns with it: 1. It removes _RWSTD_EXPORT from __rw::__rw_get_timepunct(). Is this forward binary compatible on Windows? 2. It adds a new function, __rw::__rw_get_dateorder(). Is this forward binary compatible? 3. It outlines the virtual member function time_get::do_date_order(). Is this binary compatible? time_get::date_order() should return actually date order taken from locale -- Key: STDCXX-459 URL: https://issues.apache.org/jira/browse/STDCXX-459 Project: C++ Standard Library Issue Type: Improvement Components: 22. Localization Affects Versions: 4.1.2, 4.1.3, 4.1.4 Environment: All Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Minor Fix For: 4.2.1 Attachments: stdcxx-459.patch The current implementation of the time_get::date_order() always returns no_order. It should return date order used by a locale facet (http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03734.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-673) [IBM XLC++ 9.0/AIX 5.3] 0.printf fails with assertions
[
https://issues.apache.org/jira/browse/STDCXX-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551849
]
Martin Sebor commented on STDCXX-673:
-
Incidentally, how come the 8.cstdint test hasn't been failing on AIX as a
result of the signed/unsigned mismatch? It might need to be enhanced to detect
this. Can you please look into it before you close this issue?
[IBM XLC++ 9.0/AIX 5.3] 0.printf fails with assertions
--
Key: STDCXX-673
URL: https://issues.apache.org/jira/browse/STDCXX-673
Project: C++ Standard Library
Issue Type: Bug
Components: Test Driver
Affects Versions: 4.2.0
Reporter: Travis Vitek
Assignee: Travis Vitek
Priority: Minor
Fix For: 4.2.1
Attachments: stdcxx-673.patch
extension: %{N} buffer size
/amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
rw_vasnprintf(8d0, 8d8, foo, va_list) error: errno
= 12: Not enough space
/amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
rw_vasnprintf(8d0, 8d8, foo, va_list) error: errno
= 12: Not enough space
/amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
rw_vasnprintf(8d0, 8d8, foo, va_list) error: errno
= 12: Not enough space
/amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
rw_vasnprintf(8d0, 8d8, foo, va_list) error: errno
= 12: Not enough space
/amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
rw_vasnprintf(8d0, 8d8, bar, va_list) error: errno
= 12: Not enough space
/amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
rw_vasnprintf(8d0, 8d8, bar, va_list) error: errno
= 12: Not enough space
/amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
rw_vasnprintf(8d0, 8d8, bar, va_list) error: errno
= 12: Not enough space
/amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
rw_vasnprintf(8d0, 8d8, bar, va_list) error: errno
= 12: Not enough space
extension: [EMAIL PROTECTED] nested format directive
malformed directives
Failed 8 out of 1572 assertions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-66) implement large file support in iostreams
[
https://issues.apache.org/jira/browse/STDCXX-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Sebor updated STDCXX-66:
---
Severity: Usability
Affects Version/s: 4.1.3
4.1.4
4.2.0
Fix Version/s: 5.0
Since this affects the size of std::fpos it affects the binary compatibility of
the library. Scheduled for 5.0.
implement large file support in iostreams
-
Key: STDCXX-66
URL: https://issues.apache.org/jira/browse/STDCXX-66
Project: C++ Standard Library
Issue Type: New Feature
Components: 27. Input/Output
Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0
Environment: AIX 5.2
VisualAge C++ Professional / C for AIX Compiler, Version 6
Reporter: Jeremy Dean
Priority: Minor
Fix For: 5.0
#include string
#include fstream
int main(int argc, char**argv)
{
std::ifstream i;
try
{
i.open(/tmp/largeFile.txt,std::ios::in);
if ( i.good() )
{
char s[1024];
i s ; // .getline(s, 100);
std::cout s std::endl;
}
else
{
std::cout Open error\n;
}
}
catch(...)
{
std::cout error\n;
}
return 0;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-1) allow linking with other implementations
[ https://issues.apache.org/jira/browse/STDCXX-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551937 ] Martin Sebor commented on STDCXX-1: --- I don't see how this could be done in a binary compatible way. To link with another implementation of the C++ Standard Library without running into conflicts we'd need to change the names of all the symbols that we could conflict with, i.e., everything we define out-of-line in namespace std, which is all of iostreams, locale, and strings. So I can't imagine how this could be done in 4.3. allow linking with other implementations Key: STDCXX-1 URL: https://issues.apache.org/jira/browse/STDCXX-1 Project: C++ Standard Library Issue Type: Improvement Components: Configuration Affects Versions: 4.1.2, 4.1.3, 4.1.4 Environment: All. Reporter: Martin Sebor Fix For: 4.3 This is an enhancement request to allow object files (libraries, or executable programs) compiled against this implementation of the C++ Standard Library to link with others compiled against another implementation (such as GNU libstdc++ or STLport). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-333) [gcc 3.2.3/Linux] std::wfilebuf extracts more than 1 character from a 1 byte file
[
https://issues.apache.org/jira/browse/STDCXX-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551999
]
Martin Sebor commented on STDCXX-333:
-
Couldn't reproduce with gcc 3.2.3-56 (tried 15s and 15S) on Red Hat EL 3
(Taroon Update 8) but reproduced it in a 15D buiold with gcc 4.1.0 on SuSE 10.0.
Next time though, before chasing this down, look at STDCXX-435 first!
[gcc 3.2.3/Linux] std::wfilebuf extracts more than 1 character from a 1 byte
file
-
Key: STDCXX-333
URL: https://issues.apache.org/jira/browse/STDCXX-333
Project: C++ Standard Library
Issue Type: Bug
Components: 27. Input/Output
Affects Versions: 4.1.3
Environment: gcc 3.2.3 on Linux
Reporter: Mark Brown
Assignee: Martin Sebor
Priority: Minor
I get an an abort when I run the following program on Linux.
#include cassert
#include fstream
#include iostream
int main ()
{
{
std::filebuf fb;
fb.open (file, std::ios::out);
fb.sputc ('a');
}
std::wfilebuf fb;
fb.pubimbue (std::locale (en_US.UTF-8));
fb.open (file, std::ios::in);
const int c[] = { fb.sbumpc (), fb.sgetc () };
std::cout c [0] ' ' c [1] std::endl;
assert (L'a' == c [0]);
assert (std::wfilebuf::traits_type::eof () == c [1]);
}
test: test.cpp:21: int main(): Assertion `std::wfilebuf::traits_type::eof ()
== c [1]' failed.
Aborted
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-226) __rw::__rw_new_capacity() uses floating point math
[ https://issues.apache.org/jira/browse/STDCXX-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551553 ] Martin Sebor commented on STDCXX-226: - I'm not 100% sure it can do that. The floating point environment (such as the rounding mode) during compilation might be different from runtime. Let's check the assembly on a few platforms first. __rw::__rw_new_capacity() uses floating point math -- Key: STDCXX-226 URL: https://issues.apache.org/jira/browse/STDCXX-226 Project: C++ Standard Library Issue Type: Improvement Components: 23. Containers Affects Versions: 4.1.2, 4.1.3, 4.2.0 Environment: all Reporter: Martin Sebor Assignee: Farid Zaripov Fix For: 4.2.1 Attachments: benchmark-stdcxx-226.c, new_capacity.patch Moved from the Rogue Wave bug tracking database: Created By: sebor @ May 09, 2002 11:15:41 AM The template __rw_new_capacity() uses floating point arithmetic which may be less efficient than integer arithmetic on some architectures. Need to change to integer arithmetic and correctly handle integer overflow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-524) buffer overflow in test 22.locale.time.get.cpp(make_LC_TIME)
[ https://issues.apache.org/jira/browse/STDCXX-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551615 ] Martin Sebor commented on STDCXX-524: - I've adjusted your ChangeLog to follow the established format (the date is 2007-12-12, and two spaces between name and email -- you should think about using Emacs ;-) Committed thus: http://svn.apache.org/viewvc?rev=604038view=rev Btw., since you switched to using rw_sprintf(), it occurs to me that we might as well let the function allocate the memory for the string instead of using fixed-size buffers and dispense with any risk of buffer overflow once and for all... buffer overflow in test 22.locale.time.get.cpp(make_LC_TIME) Key: STDCXX-524 URL: https://issues.apache.org/jira/browse/STDCXX-524 Project: C++ Standard Library Issue Type: Bug Components: Tests Affects Versions: 4.1.2, 4.1.3, 4.1.4 Reporter: Travis Vitek Assignee: Travis Vitek Priority: Trivial Fix For: 4.2.1 Attachments: stdcxx-524.patch This test uses L_tmpnam to determine the length of a buffer used to store a filename string. Unfortunately, L_tmpnam is intended for use with tmpnam(), but the buffer is written to with std::sprintf(). When I run the test, the allocated buffer is 46 bytes, and the sprintf() call writes 58 bytes [this will vary based on user name and other variables]. Perhaps the buffer should be made larger, or some other method should be used to fill the buffer. Perhaps this would work. #if !defined (_WIN32) !defined (_WIN64) # define _PATH_MAX PATH_MAX #else # define _PATH_MAX _MAX_PATH #endif char srcfname [_PATH_MAX]; // [L_tmpnam + 32]; std::sprintf (srcfname, %s SLASH LC_TIME.src, locale_root); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-524) buffer overflow in test 22.locale.time.get.cpp(make_LC_TIME)
[ https://issues.apache.org/jira/browse/STDCXX-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551639 ] Martin Sebor commented on STDCXX-524: - Are you saying I should be paying attention? ;-) Makes sense. buffer overflow in test 22.locale.time.get.cpp(make_LC_TIME) Key: STDCXX-524 URL: https://issues.apache.org/jira/browse/STDCXX-524 Project: C++ Standard Library Issue Type: Bug Components: Tests Affects Versions: 4.1.2, 4.1.3, 4.1.4 Reporter: Travis Vitek Assignee: Travis Vitek Priority: Trivial Fix For: 4.2.1 Attachments: stdcxx-524.patch This test uses L_tmpnam to determine the length of a buffer used to store a filename string. Unfortunately, L_tmpnam is intended for use with tmpnam(), but the buffer is written to with std::sprintf(). When I run the test, the allocated buffer is 46 bytes, and the sprintf() call writes 58 bytes [this will vary based on user name and other variables]. Perhaps the buffer should be made larger, or some other method should be used to fill the buffer. Perhaps this would work. #if !defined (_WIN32) !defined (_WIN64) # define _PATH_MAX PATH_MAX #else # define _PATH_MAX _MAX_PATH #endif char srcfname [_PATH_MAX]; // [L_tmpnam + 32]; std::sprintf (srcfname, %s SLASH LC_TIME.src, locale_root); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (STDCXX-605) [IBM XLC++] errors compiling dynatype.cpp
[
https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551653
]
sebor edited comment on STDCXX-605 at 12/13/07 4:22 PM:
---
Hmmm. I tried to change the patch to show you what I meant with the const but
I'm just getting an exception. I guess I don't understand how it works... Why
can't one overload of retrieve be const and the other non-const, like this:
template class T T retrieve (T*);
template class T const T retrieve (const T*) const;
I was hoping to then define the conversion operators like so:
template class T operator T () { return retrieve ((T*)0); }
template class T operator const T () const { return retrieve ((const
T*)0); }
But when I do this and run it I get this on stdout:
static_castconst int(v1 = 1) = exception
was (Author: sebor):
Hmmm. I tried to change the patch to show you what I meant with the const
but I'm just getting an exception. I guess I don't understand how it works...
Why can't one overload of retrieve be const and the other non-const, like this:
template class T T retrieve (T*);
template class T const T retrieve (const T*) const;
I was hoping to then define the conversion operators like so:
template class T operator T () { return retrieve ((T*)0); }
template class T operator const T () const { return retrieve ((T*)0); }
But when I do this and run it I get this on stdout:
static_castconst int(v1 = 1) = exception
[IBM XLC++] errors compiling dynatype.cpp
-
Key: STDCXX-605
URL: https://issues.apache.org/jira/browse/STDCXX-605
Project: C++ Standard Library
Issue Type: Bug
Components: Examples
Affects Versions: 4.2.0
Environment: XLC++ 6.0 through 9.0/AIX 5.3
Reporter: Martin Sebor
Assignee: Travis Vitek
Fix For: 4.2.1
Attachments: stdcxx-605.patch
The dynatype.cpp example program fails to compile with IBM XLC++ 9.0 on AIX
with ethe following errors:
xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include
-I$(BUILDDIR)/include -I$(TOPDIR)/examples/include -O -Q
-qtemplateregistry=dynatype.ti $(TOPDIR)/examples/tutorial/dynatype.cpp
$(TOPDIR)/examples/tutorial/dynatype.cpp, line 203.27: 1540-0216 (S) An
expression of type dynatype cannot be converted to type int.
$(TOPDIR)/examples/tutorial/dynatype.cpp, line 209.30: 1540-0216 (S) An
expression of type dynatype cannot be converted to type double.
$(TOPDIR)/examples/tutorial/dynatype.cpp, line 215.30: 1540-0216 (S) An
expression of type dynatype cannot be converted to type double.
$(TOPDIR)/examples/tutorial/dynatype.cpp, line 222.35: 1540-0216 (S) An
expression of type dynatype cannot be converted to type const char *.
$(TOPDIR)/examples/tutorial/dynatype.cpp, line 228.35: 1540-0216 (S) An
expression of type dynatype cannot be converted to type const char *.
$(TOPDIR)/examples/tutorial/dynatype.cpp, line 238.28: 1540-0216 (S) An
expression of type dynatype cannot be converted to type char.
gmake: *** [dynatype.o] Error 1
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-605) [IBM XLC++] errors compiling dynatype.cpp
[
https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551653
]
Martin Sebor commented on STDCXX-605:
-
Hmmm. I tried to change the patch to show you what I meant with the const but
I'm just getting an exception. I guess I don't understand how it works... Why
can't one overload of retrieve be const and the other non-const, like this:
template class T T retrieve (T*);
template class T const T retrieve (const T*) const;
I was hoping to then define the conversion operators like so:
template class T operator T () { return retrieve ((T*)0); }
template class T operator const T () const { return retrieve ((T*)0); }
But when I do this and run it I get this on stdout:
static_castconst int(v1 = 1) = exception
[IBM XLC++] errors compiling dynatype.cpp
-
Key: STDCXX-605
URL: https://issues.apache.org/jira/browse/STDCXX-605
Project: C++ Standard Library
Issue Type: Bug
Components: Examples
Affects Versions: 4.2.0
Environment: XLC++ 6.0 through 9.0/AIX 5.3
Reporter: Martin Sebor
Assignee: Travis Vitek
Fix For: 4.2.1
Attachments: stdcxx-605.patch
The dynatype.cpp example program fails to compile with IBM XLC++ 9.0 on AIX
with ethe following errors:
xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include
-I$(BUILDDIR)/include -I$(TOPDIR)/examples/include -O -Q
-qtemplateregistry=dynatype.ti $(TOPDIR)/examples/tutorial/dynatype.cpp
$(TOPDIR)/examples/tutorial/dynatype.cpp, line 203.27: 1540-0216 (S) An
expression of type dynatype cannot be converted to type int.
$(TOPDIR)/examples/tutorial/dynatype.cpp, line 209.30: 1540-0216 (S) An
expression of type dynatype cannot be converted to type double.
$(TOPDIR)/examples/tutorial/dynatype.cpp, line 215.30: 1540-0216 (S) An
expression of type dynatype cannot be converted to type double.
$(TOPDIR)/examples/tutorial/dynatype.cpp, line 222.35: 1540-0216 (S) An
expression of type dynatype cannot be converted to type const char *.
$(TOPDIR)/examples/tutorial/dynatype.cpp, line 228.35: 1540-0216 (S) An
expression of type dynatype cannot be converted to type const char *.
$(TOPDIR)/examples/tutorial/dynatype.cpp, line 238.28: 1540-0216 (S) An
expression of type dynatype cannot be converted to type char.
gmake: *** [dynatype.o] Error 1
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-673) [IBM XLC++ 9.0/AIX 5.3] 0.printf fails with assertions
[
https://issues.apache.org/jira/browse/STDCXX-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551664
]
Martin Sebor commented on STDCXX-673:
-
Okay, this sounds like a good plan for now. I checked your patch in as follows:
http://svn.apache.org/viewvc?rev=604073view=rev
We will need to revisit this issue at some point before finalizing this though
to make sure our typedefs are the same as those provided by the C library on
every system. That will require us to either autodetect the underlying type of
int8_t or hardcode it for the known platforms (conditionally, depending on the
compiler macro defined in response to the option that control the signedness of
plain chars). We'll likely end up with a combination of the two approaches.
[IBM XLC++ 9.0/AIX 5.3] 0.printf fails with assertions
--
Key: STDCXX-673
URL: https://issues.apache.org/jira/browse/STDCXX-673
Project: C++ Standard Library
Issue Type: Bug
Components: Test Driver
Affects Versions: 4.2.0
Reporter: Travis Vitek
Assignee: Travis Vitek
Priority: Minor
Fix For: 4.2.1
Attachments: stdcxx-673.patch
extension: %{N} buffer size
/amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
rw_vasnprintf(8d0, 8d8, foo, va_list) error: errno
= 12: Not enough space
/amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
rw_vasnprintf(8d0, 8d8, foo, va_list) error: errno
= 12: Not enough space
/amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
rw_vasnprintf(8d0, 8d8, foo, va_list) error: errno
= 12: Not enough space
/amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
rw_vasnprintf(8d0, 8d8, foo, va_list) error: errno
= 12: Not enough space
/amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
rw_vasnprintf(8d0, 8d8, bar, va_list) error: errno
= 12: Not enough space
/amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
rw_vasnprintf(8d0, 8d8, bar, va_list) error: errno
= 12: Not enough space
/amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
rw_vasnprintf(8d0, 8d8, bar, va_list) error: errno
= 12: Not enough space
/amd/devco/vitek/stdcxx/trunk/tests/src/printf.cpp:1022:
rw_vasnprintf(8d0, 8d8, bar, va_list) error: errno
= 12: Not enough space
extension: [EMAIL PROTECTED] nested format directive
malformed directives
Failed 8 out of 1572 assertions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-664) [IBM XLC++ 9.0/AIX 5.3] SIGABRT in 22.locale.globals.mt
[
https://issues.apache.org/jira/browse/STDCXX-664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551678
]
Martin Sebor commented on STDCXX-664:
-
I think the dynamic cast patch
(https://issues.apache.org/jira/secure/attachment/12371623/stdcxx-664-1.patch)
might be a good idea in any case. I was going to add that we might also want to
throw in a conditional for _RWSTD_NO_THREAD_SAFE_EXCEPTIONS but I see it's
already there. It would be nice if they were both handled the same way. I've
modified your patch slightly and added some changes of my own to handle both
cases consistently: http://svn.apache.org/viewvc?rev=604088view=rev
Btw., now that I've committed it I have a question for you about the comment in
the _RWSTD_NO_DYNAMIC_CAST block:
// if dynamic_cast isn't supported, then [has,use]_facet()
// can't reliably detect if a facet is installed or not.
test_has_facet() doesn't use opt_no_exceptions. Should it? Or is the mention of
has_facet in the comment not intended to relevant to the test function?
As for the other patch, I'm still undecided... But since the already committed
patch should fix the problem with the test (it no longer aborts) I think we can
close this issue and treat the question of using -qrtti=dynamiccast as a
separate issue.
[IBM XLC++ 9.0/AIX 5.3] SIGABRT in 22.locale.globals.mt
---
Key: STDCXX-664
URL: https://issues.apache.org/jira/browse/STDCXX-664
Project: C++ Standard Library
Issue Type: Bug
Components: Tests
Affects Versions: 4.2.0
Reporter: Travis Vitek
Assignee: Travis Vitek
Fix For: 4.2.1
Attachments: stdcxx-664-1.patch, stdcxx-664-2.patch
Appears to affect single-threaded bulids only.
[EMAIL PROTECTED] tests]$ ./22.locale.globals.mt
# INFO (S1) (10 lines):
# TEXT:
# COMPILER: IBM VisualAge C++, __IBMCPP__ = 900
# ENVIRONMENT: powerpc running aix-5.3
# FILE: 22.locale.globals.mt.cpp
# COMPILED: Nov 8 2007, 21:35:16
# COMMENT: thread safety
# CLAUSE: lib.locale.global.templates
# NOTE (S2) (5 lines):
# TEXT: executing locale -a /tmp/tmpfile-fK3jqa
# CLAUSE: lib.locale.global.templates
# FILE: process.cpp
# LINE: 270
# INFO (S1) (3 lines):
# TEXT: testing std::locale globals with 1 thread, 2 iterations each, in
16 locales { C POSIX AR_DZ.UTF-8 AR_BH AR_AA.UTF-8 AR_BH.UTF-8
AR_AE.UTF-8 AR_DZ AR_EG.UTF-8 AR_EG AR_AE AR_AA AR_JO
AR_JO.UTF-8 AR_KW AR_KW.UTF-8 }
# CLAUSE: lib.locale.global.templates
# INFO (S1) (3 lines):
# TEXT: template class T bool std::has_facet (const locale)
# CLAUSE: lib.locale.global.templates
# INFO (S1) (3 lines):
# TEXT: template class T const T std::use_facet (const locale)
# CLAUSE: lib.locale.global.templates
# WARNING (S5) (3 lines):
# TEXT: exceptions not thread safe, skipping that part of test
# CLAUSE: lib.locale.global.templates
/amd/devco/vitek/stdcxx-trunk/tests/localization/22.locale.globals.mt.cpp:311:
use_facet_loop: Assertion 'threw || opt_facets [opt_inx_collate] 0' failed.
IOT/Abort trap (core dumped)
[EMAIL PROTECTED] tests]$
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-605) [IBM XLC++] errors compiling dynatype.cpp
[ https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551167 ] Martin Sebor commented on STDCXX-605: - Looks like you've been able to come up with a clean solution after all -- excellent! I do have one question about the patch to make sure I understand how it works: do both overloads of retrieve() need to be const? It seems that the one returning (non-const) T should be non-const, no? (And shouldn't the call to the const overload cast the argument to const T* instead of plain T*?) Also, there are a few gratuitous whitespace edits in the patch (unnecessarily added newlines) that should normally be avoided, and a few formatting issues (missing spaces before open parens). [IBM XLC++] errors compiling dynatype.cpp - Key: STDCXX-605 URL: https://issues.apache.org/jira/browse/STDCXX-605 Project: C++ Standard Library Issue Type: Bug Components: Examples Affects Versions: 4.2.0 Environment: XLC++ 6.0 through 9.0/AIX 5.3 Reporter: Martin Sebor Assignee: Travis Vitek Fix For: 4.2.1 Attachments: stdcxx-605.patch The dynatype.cpp example program fails to compile with IBM XLC++ 9.0 on AIX with ethe following errors: xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include -I$(BUILDDIR)/include -I$(TOPDIR)/examples/include -O -Q -qtemplateregistry=dynatype.ti $(TOPDIR)/examples/tutorial/dynatype.cpp $(TOPDIR)/examples/tutorial/dynatype.cpp, line 203.27: 1540-0216 (S) An expression of type dynatype cannot be converted to type int. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 209.30: 1540-0216 (S) An expression of type dynatype cannot be converted to type double. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 215.30: 1540-0216 (S) An expression of type dynatype cannot be converted to type double. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 222.35: 1540-0216 (S) An expression of type dynatype cannot be converted to type const char *. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 228.35: 1540-0216 (S) An expression of type dynatype cannot be converted to type const char *. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 238.28: 1540-0216 (S) An expression of type dynatype cannot be converted to type char. gmake: *** [dynatype.o] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-226) __rw::__rw_new_capacity() uses floating point math
[ https://issues.apache.org/jira/browse/STDCXX-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551189 ] Martin Sebor commented on STDCXX-226: - You're right, I must have been looking at the wrong column. Mea culpa! I suspect the problem with the shift/add algorithm is in the carry as Douglas cautions in his paper. To fix it we'd probably have to drop down a level to the assembly, which I'm sure we don't want to do given that your algorithm is faster to begin with. All right then, let's go with your version. One question though: I don't see where you're changing _RWSTD_NEW_CAPACITY_RATIO to an integer. Are you? __rw::__rw_new_capacity() uses floating point math -- Key: STDCXX-226 URL: https://issues.apache.org/jira/browse/STDCXX-226 Project: C++ Standard Library Issue Type: Improvement Components: 23. Containers Affects Versions: 4.1.2, 4.1.3, 4.2.0 Environment: all Reporter: Martin Sebor Assignee: Farid Zaripov Fix For: 4.2.1 Attachments: benchmark-stdcxx-226.c, new_capacity.patch Moved from the Rogue Wave bug tracking database: Created By: sebor @ May 09, 2002 11:15:41 AM The template __rw_new_capacity() uses floating point arithmetic which may be less efficient than integer arithmetic on some architectures. Need to change to integer arithmetic and correctly handle integer overflow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-664) [IBM XLC++ 9.0/AIX 5.3] SIGABRT in 22.locale.globals.mt
[
https://issues.apache.org/jira/browse/STDCXX-664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551213
]
Martin Sebor commented on STDCXX-664:
-
Didn't someone just say how much fun XLC++ is? ;-)
Yes, I should have remembered the -qrrti flag when I saw the issue...
As for your options, I think the decision comes down to whether we just want to
fix the test and leave it up to users to decide if they want to compile with
-qrtti, or make the library behave correctly as we build it. If the former, we
could just add some preprocessor logic to the test and #ifdef out the
problematic assertions. If the latter, enabling RTTI would seem like the way to
go. IIRC, we chose to stick with the default setting of the -qrtti option for
stdcxx on the basis that we should try to avoid requiring special options as
much as possible; in our measurements, the option also lead to a slight
increase in the size of the generated code. Maybe that's changed in 9.0? If
not, I would tend to lean toward fixing the test and documenting this in the
README or someplace people are likely to look.
Regarding adding __rw_get_facet_by_id() overloads for the _byname facets, would
those be robust enough to handle the case of _byname derivates (e.g., class
MyCtype: std::ctype_bynamechar)? I.e., this test case:
#include cassert
#include locale
struct DerivedCtype: std::ctype_bynamechar
{
DerivedCtype (): std::ctype_bynamechar() { }
};
template class Facet
bool check_use_facet (const std::locale locale)
{
try {
std::use_facetFacet(locale);
}
catch (...) {
return false;
}
return true;
}
int main ()
{
const std::locale classic = std::locale::classic ();
const std::locale named (en_US.ISO-8859-1);
const std::locale user (classic, new DerivedCtype);
assert (check_use_facetstd::ctypechar (classic));
assert (!check_use_facetstd::ctype_bynamechar (classic));
assert (!check_use_facetDerivedCtype(classic));
assert (check_use_facetstd::ctypechar (named));
assert (check_use_facetstd::ctype_bynamechar (named));
assert (!check_use_facetDerivedCtype(named));
assert (check_use_facetstd::ctypechar (user));
assert (check_use_facetstd::ctype_bynamechar (user));
assert (check_use_facetDerivedCtype(user));
}
[IBM XLC++ 9.0/AIX 5.3] SIGABRT in 22.locale.globals.mt
---
Key: STDCXX-664
URL: https://issues.apache.org/jira/browse/STDCXX-664
Project: C++ Standard Library
Issue Type: Bug
Components: Tests
Affects Versions: 4.2.0
Reporter: Travis Vitek
Assignee: Travis Vitek
Fix For: 4.2.1
Appears to affect single-threaded bulids only.
[EMAIL PROTECTED] tests]$ ./22.locale.globals.mt
# INFO (S1) (10 lines):
# TEXT:
# COMPILER: IBM VisualAge C++, __IBMCPP__ = 900
# ENVIRONMENT: powerpc running aix-5.3
# FILE: 22.locale.globals.mt.cpp
# COMPILED: Nov 8 2007, 21:35:16
# COMMENT: thread safety
# CLAUSE: lib.locale.global.templates
# NOTE (S2) (5 lines):
# TEXT: executing locale -a /tmp/tmpfile-fK3jqa
# CLAUSE: lib.locale.global.templates
# FILE: process.cpp
# LINE: 270
# INFO (S1) (3 lines):
# TEXT: testing std::locale globals with 1 thread, 2 iterations each, in
16 locales { C POSIX AR_DZ.UTF-8 AR_BH AR_AA.UTF-8 AR_BH.UTF-8
AR_AE.UTF-8 AR_DZ AR_EG.UTF-8 AR_EG AR_AE AR_AA AR_JO
AR_JO.UTF-8 AR_KW AR_KW.UTF-8 }
# CLAUSE: lib.locale.global.templates
# INFO (S1) (3 lines):
# TEXT: template class T bool std::has_facet (const locale)
# CLAUSE: lib.locale.global.templates
# INFO (S1) (3 lines):
# TEXT: template class T const T std::use_facet (const locale)
# CLAUSE: lib.locale.global.templates
# WARNING (S5) (3 lines):
# TEXT: exceptions not thread safe, skipping that part of test
# CLAUSE: lib.locale.global.templates
/amd/devco/vitek/stdcxx-trunk/tests/localization/22.locale.globals.mt.cpp:311:
use_facet_loop: Assertion 'threw || opt_facets [opt_inx_collate] 0' failed.
IOT/Abort trap (core dumped)
[EMAIL PROTECTED] tests]$
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-664) [IBM XLC++ 9.0/AIX 5.3] SIGABRT in 22.locale.globals.mt
[
https://issues.apache.org/jira/browse/STDCXX-664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551216
]
Martin Sebor commented on STDCXX-664:
-
FWIW, the test case above fails with gcc 4.1.2. I filed a bug for it:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34449
[IBM XLC++ 9.0/AIX 5.3] SIGABRT in 22.locale.globals.mt
---
Key: STDCXX-664
URL: https://issues.apache.org/jira/browse/STDCXX-664
Project: C++ Standard Library
Issue Type: Bug
Components: Tests
Affects Versions: 4.2.0
Reporter: Travis Vitek
Assignee: Travis Vitek
Fix For: 4.2.1
Appears to affect single-threaded bulids only.
[EMAIL PROTECTED] tests]$ ./22.locale.globals.mt
# INFO (S1) (10 lines):
# TEXT:
# COMPILER: IBM VisualAge C++, __IBMCPP__ = 900
# ENVIRONMENT: powerpc running aix-5.3
# FILE: 22.locale.globals.mt.cpp
# COMPILED: Nov 8 2007, 21:35:16
# COMMENT: thread safety
# CLAUSE: lib.locale.global.templates
# NOTE (S2) (5 lines):
# TEXT: executing locale -a /tmp/tmpfile-fK3jqa
# CLAUSE: lib.locale.global.templates
# FILE: process.cpp
# LINE: 270
# INFO (S1) (3 lines):
# TEXT: testing std::locale globals with 1 thread, 2 iterations each, in
16 locales { C POSIX AR_DZ.UTF-8 AR_BH AR_AA.UTF-8 AR_BH.UTF-8
AR_AE.UTF-8 AR_DZ AR_EG.UTF-8 AR_EG AR_AE AR_AA AR_JO
AR_JO.UTF-8 AR_KW AR_KW.UTF-8 }
# CLAUSE: lib.locale.global.templates
# INFO (S1) (3 lines):
# TEXT: template class T bool std::has_facet (const locale)
# CLAUSE: lib.locale.global.templates
# INFO (S1) (3 lines):
# TEXT: template class T const T std::use_facet (const locale)
# CLAUSE: lib.locale.global.templates
# WARNING (S5) (3 lines):
# TEXT: exceptions not thread safe, skipping that part of test
# CLAUSE: lib.locale.global.templates
/amd/devco/vitek/stdcxx-trunk/tests/localization/22.locale.globals.mt.cpp:311:
use_facet_loop: Assertion 'threw || opt_facets [opt_inx_collate] 0' failed.
IOT/Abort trap (core dumped)
[EMAIL PROTECTED] tests]$
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-226) __rw::__rw_new_capacity() uses floating point math
[ https://issues.apache.org/jira/browse/STDCXX-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550775 ] Martin Sebor commented on STDCXX-226: - We still need to benchmark this before making any changes... Currently, we get the new capacity by multiplying the current value by an approximation of the Golden Ratio (http://en.wikipedia.org/wiki/Golden_ratio), or 1.618: z = x * 1.618 I suspect that the closest we'll be able to come to this value using integer operations without incurring a significant performance penalty is by multiplying the current value by 16 and dividing the result by 10. We can avoid the expensive division by 10 by approximating the operations using reciprocal multiplication as described below. I.e., like so: z = x 4; z = ((z 1) + z) 1; z = ((z 4) + z); z = ((z 8) + z); z = ((z 16) + z) 3; http://www.cs.uiowa.edu/~jones/bcd/divide.html I put together a simple benchmark to compare the performance of the original algorithm to that of the new one. I also included the approach I describe here because it seems to produce results that are closer to the original. The benchmark shows that eliminating the FP operations yields a dramatic improvement (an order of magnitude or more) on all architectures (x86, IA64, PA-RISC, PowerPC, or SPARC) regardless of which of the two approaches we go with. The algorithm in your patch performs slightly better than the alternative here (between 10% and up to twice as fast, depending on the hardware architecture) but yields results that are considerably less accurate than the alternative (I haven't measured by how much). So unless you think the performance gain is more important, I think we should go with the alternative I presented here. __rw::__rw_new_capacity() uses floating point math -- Key: STDCXX-226 URL: https://issues.apache.org/jira/browse/STDCXX-226 Project: C++ Standard Library Issue Type: Improvement Components: 23. Containers Affects Versions: 4.1.2, 4.1.3, 4.2.0 Environment: all Reporter: Martin Sebor Assignee: Farid Zaripov Fix For: 4.2.1 Attachments: new_capacity.patch Moved from the Rogue Wave bug tracking database: Created By: sebor @ May 09, 2002 11:15:41 AM The template __rw_new_capacity() uses floating point arithmetic which may be less efficient than integer arithmetic on some architectures. Need to change to integer arithmetic and correctly handle integer overflow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-226) __rw::__rw_new_capacity() uses floating point math
[ https://issues.apache.org/jira/browse/STDCXX-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-226: Attachment: benchmark-stdcxx-226.c Attached simple benchmark program to compare the runtime performance of the three approaches discussed in the issue. Compiled with any C compiler, run as follows: $ time ./a.out [ 0 | 1 | 2 ] N 0 for the original algorithm 1 for the algorithm implemented in the attached patch 2 for the reciprocal multiplication approach N the number of iterations (unsigned long) __rw::__rw_new_capacity() uses floating point math -- Key: STDCXX-226 URL: https://issues.apache.org/jira/browse/STDCXX-226 Project: C++ Standard Library Issue Type: Improvement Components: 23. Containers Affects Versions: 4.1.2, 4.1.3, 4.2.0 Environment: all Reporter: Martin Sebor Assignee: Farid Zaripov Fix For: 4.2.1 Attachments: benchmark-stdcxx-226.c, new_capacity.patch Moved from the Rogue Wave bug tracking database: Created By: sebor @ May 09, 2002 11:15:41 AM The template __rw_new_capacity() uses floating point arithmetic which may be less efficient than integer arithmetic on some architectures. Need to change to integer arithmetic and correctly handle integer overflow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-650) 22.locale.codecvt.out test fails to compile
[ https://issues.apache.org/jira/browse/STDCXX-650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor closed STDCXX-650. --- Fix verified in nightly builds. Merged to 4.2.1 in http://svn.apache.org/viewvc?view=revrevision=603470 Closing... 22.locale.codecvt.out test fails to compile --- Key: STDCXX-650 URL: https://issues.apache.org/jira/browse/STDCXX-650 Project: C++ Standard Library Issue Type: Bug Components: Tests Affects Versions: 4.2.0 Reporter: Travis Vitek Assignee: Martin Sebor Fix For: 4.2.1 There is actually nothing wrong with the test itself. The problem is the name of the test. The makefile has rules for .out files, and when trying to build the executable 22.locale.codecvt.out, it thinks you are talking about a .out file, not an executable, so it does nothing. Renaming the source file to 22.locale.codecvt.outx.cpp avoids the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-647) [MSVC] 0.printf.cpp test fails
[
https://issues.apache.org/jira/browse/STDCXX-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Sebor reassigned STDCXX-647:
---
Assignee: Farid Zaripov
[MSVC] 0.printf.cpp test fails
--
Key: STDCXX-647
URL: https://issues.apache.org/jira/browse/STDCXX-647
Project: C++ Standard Library
Issue Type: Bug
Components: Tests
Affects Versions: 4.2.0
Environment: MSVC, ICC/Windows
Reporter: Farid Zaripov
Assignee: Farid Zaripov
Priority: Minor
Fix For: 4.2.1
The 0.printf.cpp test fails with 36 assertions due to STDCXX-646:
# Assertion failed on line 2076: rw_sprintf([%{$NULL-word}], ...) == [],
got [word]
# Assertion failed on line 2092: rw_sprintf([%{$NULL=word}], ...) == [],
got [word]
# Assertion failed on line 2103: rw_sprintf([%{$UNSET:?word}], ...) ==
[%{$UNSET:?word}], got [word]
# Assertion failed on line 2107: rw_sprintf([%{$NULL?word}], ...) == [],
got [%{$NULL?word}]
# Assertion failed on line 2108: rw_sprintf([%{$UNSET?word}], ...) ==
[%{$UNSET?word}], got [word]
# Assertion failed on line 2113: rw_sprintf([%{$UNSET:+word}], ...) ==
[], got [word]
# Assertion failed on line 2117: rw_sprintf([%{$NULL+word}], ...) ==
[word], got []
# Assertion failed on line 2118: rw_sprintf([%{$UNSET+word}], ...) == [],
got [word]
# Assertion failed on line 2128: rw_sprintf([%{$*:-WORD}], ...) ==
[WORD], got [word]
# Assertion failed on line 2131: rw_sprintf([%{$*-WORD}], ...) == [], got
[WORD]
# Assertion failed on line 2132: rw_sprintf([%{$*-WORD}], ...) == [WORD],
got [word]
# Assertion failed on line 2137: rw_sprintf([%{$*:=WORD}], ...) ==
[WORD], got [word]
# Assertion failed on line 2138: rw_sprintf([%{$*}], ...) == [WORD], got
[word]
# Assertion failed on line 2145: rw_sprintf([%{$*=WORD}], ...) == [], got
[WORD]
# Assertion failed on line 2146: rw_sprintf([%{$*=WORD}], ...) == [WORD],
got [word]
# Assertion failed on line 2147: rw_sprintf([%{$*}], ...) == [WORD], got
[word]
# Assertion failed on line 2155: rw_sprintf([%{$*:?WORD}], ...) ==
[%{$*:?WORD}], got [word]
# Assertion failed on line 2158: rw_sprintf([%{$*?WORD}], ...) == [], got
[%{$*?WORD}]
# Assertion failed on line 2159: rw_sprintf([%{$*?WORD}], ...) ==
[%{$*?WORD}], got [word]
# Assertion failed on line 2163: rw_sprintf([%{$*:+WORD}], ...) == [],
got [WORD]
# Assertion failed on line 2166: rw_sprintf([%{$*+WORD}], ...) == [WORD],
got []
# Assertion failed on line 2167: rw_sprintf([%{$*+WORD}], ...) == [], got
[WORD]
# Assertion failed on line 2173: rw_sprintf([%{$*:-*}], ...) == [WORD],
got [word]
# Assertion failed on line 2176: rw_sprintf([%{$*-*}], ...) == [], got
[WORD]
# Assertion failed on line 2177: rw_sprintf([%{$*-*}], ...) == [WORD],
got [word]
# Assertion failed on line 2182: rw_sprintf([%{$*:=*}], ...) == [WORD],
got [word]
# Assertion failed on line 2183: rw_sprintf([%{$*}], ...) == [WORD], got
[word]
# Assertion failed on line 2190: rw_sprintf([%{$*=*}], ...) == [], got
[WORD]
# Assertion failed on line 2191: rw_sprintf([%{$*=*}], ...) == [WORD],
got [word]
# Assertion failed on line 2192: rw_sprintf([%{$*}], ...) == [WORD], got
[word]
# Assertion failed on line 2200: rw_sprintf([%{$*:?*}], ...) ==
[%{$*:?*}], got [word]
# Assertion failed on line 2203: rw_sprintf([%{$*?*}], ...) == [], got
[%{$*?*}]
# Assertion failed on line 2204: rw_sprintf([%{$*?*}], ...) == [%{$*?*}],
got [word]
# Assertion failed on line 2208: rw_sprintf([%{$*:+*}], ...) == [], got
[WORD]
# Assertion failed on line 2211: rw_sprintf([%{$*+*}], ...) == [WORD],
got []
# Assertion failed on line 2212: rw_sprintf([%{$*+*}], ...) == [], got
[WORD]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-507) [Cygwin] Access violation while loading libstdxxx.dll in dynamic builds
[ https://issues.apache.org/jira/browse/STDCXX-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550194 ] Martin Sebor commented on STDCXX-507: - The the thread below for a discussion of this issue: http://www.nabble.com/-PATCH--STDCXX-507--28or-using-__declspec-28dllexport-dllimport-on-gcc-cygwin-in-shared-builds-29-to14217944.html#a14217944 [Cygwin] Access violation while loading libstdxxx.dll in dynamic builds --- Key: STDCXX-507 URL: https://issues.apache.org/jira/browse/STDCXX-507 Project: C++ Standard Library Issue Type: Bug Components: Build Affects Versions: 4.2.0 Environment: gcc 3.4.4/Cygwin Reporter: Farid Zaripov Assignee: Farid Zaripov Fix For: 4.2.1 Attachments: cygwin.patch, localedef.imports Many utilities, examples and tests failed to start due to access violation while loading libstdxxx.dll. In night builds logs they all finished with status 5. The reason is access violation while loading libstdxxx.dll. All of them has many times duplicated imports (see the attached file) and I suppose that bug in ld utility. $ ./localedef || echo $? 5 $ strace /usr/src/stdcxx/trunk/build15d/bin/localedef --- Process 732, exception C005 at 7C919994 --- Process 732, exception C005 at 7C964ED1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-585) [gcc 4.2.0/Cygwin] linker errors due to multiple definition of `std::bad_cast::what()'; `std::bad_typeid::what()'; `std::bad_exception::what()'; `std::bad_alloc::what()'
[ https://issues.apache.org/jira/browse/STDCXX-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549876 ] Martin Sebor commented on STDCXX-585: - I assume the patch has tested successfully with all compilers on both Linux and Windows. If that's correct, let's check it in and keep a close eye on all the other platforms to see what happens and be ready to revert it if it breaks things too badly. [gcc 4.2.0/Cygwin] linker errors due to multiple definition of `std::bad_cast::what()'; `std::bad_typeid::what()'; `std::bad_exception::what()'; `std::bad_alloc::what()' - Key: STDCXX-585 URL: https://issues.apache.org/jira/browse/STDCXX-585 Project: C++ Standard Library Issue Type: Bug Components: Configuration Affects Versions: 4.2.0 Environment: gcc 4.2.0 / Cygwin Reporter: Farid Zaripov Assignee: Farid Zaripov Priority: Blocker Fix For: 4.2.1 Attachments: BAD_ALLOC_ASSIGNMENT.cpp.diff When building the stdcxx on Cygwin I get errors like: make: Entering directory `/usr/src/stdcxx/trunk/build/examples' gcc -c -I/usr/src/stdcxx/trunk/include/ansi -D_RWSTDDEBUG -D_REENTRANT -mthreads -I/usr/src/stdcxx/trunk/include -I/usr/src/stdcxx/trunk/build/include -I/usr/src/stdcxx/trunk/examples/include -pedantic -nostdinc++ -g -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align /usr/src/stdcxx/trunk/examples/manual/accumulate.cpp gcc accumulate.o -o accumulate -mthreads -L/usr/src/stdcxx/trunk/build/lib -lstd15s -lsupc++ -lcatgets -liconv -lm /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(tinfo.o): In function `_ZNK10__cxxabiv121__vmi_class_type_info12__do_dyncastEiNS_17__class_type_info10__sub_kindEPKS1_PKvS4_S6_RNS1_16__dyncast_resultE': /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/tinfo.cc:418: multiple definition of `std::bad_cast::what() const' /usr/src/stdcxx/trunk/build/lib/libstd15s.a(typeinfo.o):/usr/src/stdcxx/trunk/src/typeinfo.cpp:349: first defined here /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(tinfo.o): In function `_ZNK10__cxxabiv121__vmi_class_type_info12__do_dyncastEiNS_17__class_type_info10__sub_kindEPKS1_PKvS4_S6_RNS1_16__dyncast_resultE': /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/tinfo.cc:418: multiple definition of `std::bad_typeid::what() const' /usr/src/stdcxx/trunk/build/lib/libstd15s.a(typeinfo.o):/usr/src/stdcxx/trunk/src/typeinfo.cpp:414: first defined here /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(new_handler.o): In function `_ZNSt9bad_allocD2Ev': /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/new_handler.cc:48: multiple definition of `std::bad_alloc::what() const' /usr/src/stdcxx/trunk/build/lib/libstd15s.a(memory.o):/usr/src/stdcxx/trunk/src/memory.cpp:331: first defined here /usr/local/lib/gcc/i686-pc-cygwin/4.2.0/../../../libsupc++.a(eh_exception.o): In function `_ZNSt13bad_exceptionD2Ev': /usr/src/gcc-4.2.0/i686-pc-cygwin/libstdc++-v3/libsupc++/../../.././libstdc++-v3/libsupc++/eh_exception.cc:38: multiple definition of `std::bad_exception::what() const' /usr/src/stdcxx/trunk/build/lib/libstd15s.a(exception.o):/usr/src/stdcxx/trunk/src/exception.cpp:412: first defined here collect2: ld returned 1 exit status make: *** [accumulate] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-308) [LWG #622] std::filebuf dtor doesn't close fd after exception
[
https://issues.apache.org/jira/browse/STDCXX-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Sebor updated STDCXX-308:
Severity: Incorrect Behavior
Affects Version/s: 4.1.4
4.2.0
This affects all released versions.
[LWG #622] std::filebuf dtor doesn't close fd after exception
-
Key: STDCXX-308
URL: https://issues.apache.org/jira/browse/STDCXX-308
Project: C++ Standard Library
Issue Type: Bug
Components: 27. Input/Output
Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0
Environment: all
Reporter: Martin Sebor
Assignee: Martin Sebor
Fix For: 4.2.1
Original Message
Subject: Re: aCC 3.70 -AA fd's close not being called.
Date: Thu, 7 Dec 2006 23:17:55 -0800 (PST)
From: Dennis Handly [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
It appears this problem is still in the apache code:
http://svn.apache.org/repos/asf/incubator/stdcxx/trunk/include/fstream.cc
It seems to violate 27.8.1.3(6), which says it always finally calls
as if fclose(3). And returns an error if any calls fail.
From: Levie, Barry [EMAIL PROTECTED]
Date: Thu, 7 Dec 2006 15:36:33 -
Subject: aCC 3.70 -AA fd's close not being called.
I am not sure if this exactly represents the problem the customer is
having as I am still waiting for more details (versions/test case etc
etc). However this could be close and I think it shows a problem.
Why does the ofstream destructor not close the file descriptor when its
called after its thrown an exception for out of disk space.
This aCC 3.70 -AA example shows an ever increasing number of open file
descriptors in glance
# what /usr/lib/libstd_v2.2:
HP aC++ B3910B A.03.30 C++ Standard Library (RogueWave Version 2.02.01)
#include iostream
#include fstream
#include string.h
using namespace std;
struct dummy {
dummy() { cout \ndummy created \n ;}
~dummy() { cout \ndummy deleted \n; }
};
void bar() {
char buf[1024*1024];
memset(buf,'A',1024*1024);
buf[1024*1024 -1] = 0;
ofstream of;
dummy df;
of.exceptions(ofstream::eofbit | ofstream::failbit | ofstream::badbit);
try {
of.open(/home/test.txt); // this is on a volume that is nearly full.
while(1) {
of buf;
}
}
catch(ofstream::failure e) {
cout \nException write/file;
}
}
int main () {
while(1) bar();
}
# ./a.out
dummy created
msgcnt 160 vxfs: mesg 001: vx_nospace - /dev/vg00/lvol5 file system full
(1 block extent)
Exception write/file
dummy deleted
Glance output shows
D File Name Type Mode Count Offset
---
0 /dev/pts/tastream rd/wr 6 333822
1 /dev/pts/tastream rd/wr 6 333822
2 /dev/pts/tastream rd/wr 6 333822
3 /home/test.txt regwrite 1 101957632
4 /home/test.txt regwrite 1 101957632
5 /home/test.txt regwrite 1 101957632
...
From: Dennis Handly [EMAIL PROTECTED]
Date: Thu, 7 Dec 2006 23:03:08 -0800 (PST)
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: aCC 3.70 -AA fd's close not being called.
From: Levie, Barry [EMAIL PROTECTED]
I am not sure if this exactly represents the problem the customer is
having as I am still waiting for more details (versions/test case etc
etc). However this could be close and I think it shows a problem.
Why does the ofstream destructor not close the file descriptor when its
called after its thrown an exception for out of disk space.
A highly modified version works for me.
And it isn't closed on the throw but by falling off the bar body.
This aCC 3.70 -AA example shows an ever increasing number of open file
descriptors in glance
Hmm.
# what /usr/lib/libstd_v2.2:
HP aC++ B3910B A.03.30 C++ Standard Library (RogueWave Version 2.02.01)
This obsolete version isn't supported.
Here is what I have and it shows close being called after I throw.
I've manually modified the write return to -1 and that throws and is caught.
(The debugger was broken and it didn't really happen. )-:
#include iostream
#include fstream
#include string.h
#include stdio.h
using namespace std;
struct dummy {
dummy() { fprintf(stdout, dummy created\n); fflush(stdout); }
~dummy() { fprintf(stdout, dummy deleted\n); fflush(stdout); }
};
extern C int _close(int fd);
extern C int close(int fd) {
if (fd STDERR_FILENO) {
fprintf(stdout, close(%d)\n, fd);
fflush(stdout);
}
return _close(fd);
}
char buf[1024];
void bar() {
