Re: [PATCH] _mutex.h
From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Ср, 02.01.2008 20:41 To: stdcxx-dev@incubator.apache.org Subject: Re: [PATCH] _mutex.h +extern C long __cdecl _InterlockedIncrement (long volatile*); +extern C long __cdecl _InterlockedDecrement (long volatile*); +extern C long __cdecl _InterlockedExchange (long volatile*, long); Shouldn't the type of the argument be _RWSTD_INTERLOCKED_T* instead? No. _RWSTD_INTERLOCKED_T #defined only for 32-bit compiler, while intrinsic functions are available in 32 and 64-bit compilers. If not, our convention is to put the cv-qualifier(s) before the type, not after it (i.e., const T* or volatile T*, rather than T const* or T volatile*). Farid.
Re: svn commit: r612428 - /stdcxx/branches/4.2.x/include/rw/_config-msvcrt.h
[EMAIL PROTECTED] wrote: Author: faridz Date: Wed Jan 16 04:04:48 2008 New Revision: 612428 URL: http://svn.apache.org/viewvc?rev=612428view=rev Log: 2008-01-16 Farid Zaripov [EMAIL PROTECTED] * include/rw/_config-msvcrt.h: Don't #define _RWSTD_NO_LONG_LONG as __int64 if long long type is supported by compiler. IIRC, this was hardcoded to work around an MSVC 7 bug that rejected long long and unsigned long long overloads. I don't have access to 7.0 at the moment to check but if you do and can confirm this we might want to make the change conditional on 7.1 and better. Martin Modified: stdcxx/branches/4.2.x/include/rw/_config-msvcrt.h Modified: stdcxx/branches/4.2.x/include/rw/_config-msvcrt.h URL: http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/include/rw/_config-msvcrt.h?rev=612428r1=612427r2=612428view=diff == --- stdcxx/branches/4.2.x/include/rw/_config-msvcrt.h (original) +++ stdcxx/branches/4.2.x/include/rw/_config-msvcrt.h Wed Jan 16 04:04:48 2008 @@ -89,7 +89,9 @@ #endif // _RWSTD_NO_STATIC_CONST_MEMBER_DEFINITION // enable iostream and locale support for long long integers -#define _RWSTD_LONG_LONG __int64 +#ifdef _RWSTD_NO_LONG_LONG +# define _RWSTD_LONG_LONG __int64 +#endif #if defined (_WIN64) // FIXME: handle by forward declaring fuctions in rw/_mutex.h
[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=12559566#action_12559566 ] Eric Lemings commented on STDCXX-692: - The BUILDMODE was 'debug,pthreads,shared' -- my preferred build mode. I forget the exact details of the crash. I'll have to rerun it again to get stack trace and such. If someone is still running Tiger, it would be interesting to note whether it works on 10.4 or not. [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.
[Fwd: [jira] Resolved: (INFRA-1466) svn commits not showing up in Jira]
FYI, in case someone runs into the missing Subversion Commits problem in Jira again, here's what's going on and how to fix it. Original Message Subject: [jira] Resolved: (INFRA-1466) svn commits not showing up in Jira Date: Wed, 16 Jan 2008 04:01:10 -0800 (PST) From: Jeff Turner (JIRA) [EMAIL PROTECTED] To: [EMAIL PROTECTED] [ https://issues.apache.org/jira/browse/INFRA-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Turner resolved INFRA-1466. Resolution: Fixed Assignee: Jeff Turner This is due to some very stupid behaviour in the latest Subversion plugin, which deactivates itself if any error occurs contacting svn, and never reactivates itself. I've logged it at: http://jira.atlassian.com/browse/SVN-181 In the meanwhile, for JIRA admins: if the Subversion tab ever disappears again, please check the new Subversion link in the admin section, and reactivate it if it's deactivated. svn commits not showing up in Jira -- Key: INFRA-1466 URL: https://issues.apache.org/jira/browse/INFRA-1466 Project: Infrastructure Issue Type: Bug Security Level: public(Regular issues) Components: JIRA Reporter: Martin Sebor Assignee: Jeff Turner A commit that took place over 30 hours ago is yet to show up in the referenced Jira issue: http://svn.apache.org/viewvc?view=revrevision=610576 http://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel See the discussion below for some background into this: http://www.nabble.com/Re%3A-svn-commit%3A-r610576---in--incubator-stdcxx-trunk-examples-tutorial%3A-dynatype.cpp-out-dynatype.out-to14747987.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-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.
Resolving/Closing bugs
Looks like the Subversion Jira plugin is (was) acting up again and the Subversion Commits tab doesn't (didn't) show commits made to fix issues. I did as Jeff suggested in his comment on INFRA-1466 and the commits seem to have reappeared. However, since not everyone has Jira admin permissions I would like to suggest that committers adopt the convention to add a link to the change(s) committed to fix an issue in their closing comments on the issue (either when Closing or Resolving the issue). That way everyone will be able to find/verify that a fix has, in fact, been committed, even when the plugin is disabled. Farid has been using this convention for a while now so refer to one of his issues for an example. E.g., https://issues.apache.org/jira/browse/STDCXX-669 Thanks Martin
Re: [Fwd: [jira] Resolved: (INFRA-1466) svn commits not showing up in Jira]
Martin Sebor wrote: FYI, in case someone runs into the missing Subversion Commits problem in Jira again, here's what's going on and how to fix it. Btw., if you're bothered by this problem I encourage you to add your vote to the Jira Plugin Jira that Jeff opened for the issue at: http://jira.atlassian.com/browse/SVN-181 Martin Original Message Subject: [jira] Resolved: (INFRA-1466) svn commits not showing up in Jira Date: Wed, 16 Jan 2008 04:01:10 -0800 (PST) From: Jeff Turner (JIRA) [EMAIL PROTECTED] To: [EMAIL PROTECTED] [ https://issues.apache.org/jira/browse/INFRA-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Turner resolved INFRA-1466. Resolution: Fixed Assignee: Jeff Turner This is due to some very stupid behaviour in the latest Subversion plugin, which deactivates itself if any error occurs contacting svn, and never reactivates itself. I've logged it at: http://jira.atlassian.com/browse/SVN-181 In the meanwhile, for JIRA admins: if the Subversion tab ever disappears again, please check the new Subversion link in the admin section, and reactivate it if it's deactivated. svn commits not showing up in Jira -- Key: INFRA-1466 URL: https://issues.apache.org/jira/browse/INFRA-1466 Project: Infrastructure Issue Type: Bug Security Level: public(Regular issues) Components: JIRA Reporter: Martin Sebor Assignee: Jeff Turner A commit that took place over 30 hours ago is yet to show up in the referenced Jira issue: http://svn.apache.org/viewvc?view=revrevision=610576 http://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel See the discussion below for some background into this: http://www.nabble.com/Re%3A-svn-commit%3A-r610576---in--incubator-stdcxx-trunk-examples-tutorial%3A-dynatype.cpp-out-dynatype.out-to14747987.html
[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.
