Re: stdcxx on builds.apache.org
Another one job added: MSVC 9.0-x64 on Windows 2003 Server, buildtype 15D: https://builds.apache.org/job/stdcxx-4.2.2-15D-windows/ Farid. On 10.02.2012 21:57, Farid Zaripov wrote: Hi All. I have installed two jobs on builds.apache.org: 1. gcc on ubuntu, buildtype 12d: https://builds.apache.org/job/stdcxx-4.2.2-12d-ubuntu/ 2. sunpro on solaris, buildtype 15s: https://builds.apache.org/job/stdcxx-4.2.2-15s-solaris/ There's also available windows, freebsd and osx, I will add new jobs later. Any comments are appreciated. Farid.
stdcxx on builds.apache.org
Hi All. I have installed two jobs on builds.apache.org: 1. gcc on ubuntu, buildtype 12d: https://builds.apache.org/job/stdcxx-4.2.2-12d-ubuntu/ 2. sunpro on solaris, buildtype 15s: https://builds.apache.org/job/stdcxx-4.2.2-15s-solaris/ There's also available windows, freebsd and osx, I will add new jobs later. Any comments are appreciated. Farid.
Re: [VOTE] Retirement of stdcxx to the 'Attic'?
On 02.02.2012 19:03, William A. Rowe Jr. wrote: Fans and contributors, it appears that the stdcxx project is entirely dormant. The ASF has launched a new 'Attic' project over the past two years, to neatly retire dormant works until and unless a community comes along who wishes to revive the effort. As a simple formality your votes please; [ ] +1 - stdcxx committee should be retired, with code sent to the Attic [X] -1 - No, stdcxx should not fold, I am still contributing, and [would serve|am serving] on its project management committee The results of this vote will be taken up by the ASF Board of Directors at their 15 Feb meeting. I have not too much time for active developing the stdcxx, but I can review user patches, test them on a set of Microsoft compilers and commit into svn. In the other words, I can provide support of the stdcxx to the users if any exist :). Also I plan to smoothly move the stdcxx in the C++ 0x direction. So my vote is: -1 Farid.
Re: [disscuss] Retirement of stdcxx to the 'Attic'?
On 03.02.2012 1:52, Stefan Teleman wrote: 2. Someone with stdcxx commit privileges should be part of this reunification (for obvious reasons). It is very discouraging to submit patches knowing full well and ahead of time that they will never make it anywhere. Perhaps the process of submitting patches could be somewhat less of a process. Just my 0.02. --Stefan Stefan, if you split the all your patches to a set of small finalized changes and submit them through a set of corresponding issues in JIRA, I promise I will process them all one by one. At the moment I don't see any issues, reported by you. Sorry, but process is a process. Farid.
Re: std::length_error in language support library
It turns out that there already is an issue to revert this change:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#805
If Microsoft implemented the resolution of issue 624 they will
need to revert it.
I've reopened the issue with quoting text from CWG issue 805.
(https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Feedb
ackID=457862)
If you can devise a test case that triggers an exception from any
shared_ptr operation in the Microsoft implementation it would be
enough to file a bug report with them and might help convince them
to take std::length_error out of the runtime library.
Unfortunately, it is not possible. It is the same as make test that
triggers an exception from the following code:
void foo(args)
{
if (false)
throw std::length_error();
else
do_something(args);
}
Farid.
std::length_error in language support library
Looking at the latest draft of the C++ standard (n2914.pdf) it appears, that the std::length_error can be defined in language support library. This is the result of resolution of the CWG issue #624: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#624 5.4.3 p7: -- 7 When the value of the expression in a noptr-new-declarator is zero, the allocation function is called to allocate an array with no elements. If the value of that expression is such that the size of the allocated object would exceed the implementation-defined limit, no storage is obtained and the new-expression terminates by throwing an exception of a type that would match a handler (15.3) of type std::length_error (19.2.4). -- Farid
Re: [jira] Created: (STDCXX-1022) [MSVC x86 / optimized] ICE in std::__make_heap()
This is close to what I had in mind when I saw the #ifdef but is it the same thing? IIUC, in the original version, the loop will execute at least once. In this version, it may not execute at all (i.e., if __parent is zero). In the original version __parent is 0 only for __dist in [ 1; 2; 3 ]. In this version __parent is 1 (will become 0 before calling __adjust_heap() due to predecrement) for __dist in [ 2; 3 ]. But when __dist == 1 (the heap contain's the exactly one element) there's no sence to call __adjust_heap(). Farid.
Re: [jira] Created: (STDCXX-1022) [MSVC x86 / optimized] ICE in std::__make_heap()
Did you happen to reduce this to a small test case and send
it to Microsoft?
Not yet. It's difficult to create the small test.
Do you see the ICE in a specific test (or example), maybe only for a
specific instantiation of the template, or does it happen regardless
of the actual types of the template arguments?
Today I've made some investigations:
1. the 25.heap, 25.partial.sort and 25.sort tests from trunk and 4.3.x branch
are compiled withoud ICE;
2. the only difference between preprocessed 25.heap tests from 4.2.x branch and
trunk is
-
Comparing files 42x.i and trunk.i
* 42x.i
void __declspec (noreturn)
__rw_assert_fail (const char*, const char*, int, const char*)
* trunk.i
void
__rw_assert_fail (const char*, const char*, int, const char*)
*
-
3. removing _RWSTD_NORETURN from declaration of the __rw_assert_fail()
eliminates
the ICE in tests from 4.2.x branch;
4. The __rw_assert_fail() is used in RandomAccessIter methods thus RW_ASSERT
macro;
So I guess, that MSVC issues ICE when processing infinite for-loop (loop
without condition)
with __declspec (noreturn) function inside the loop.
Btw., the reason I ask is so we can come up with a better/cleaner
workaround, hopefully one that will be as efficient as the original
code and won't need an #ifdef.
I've just added condition in for-loop, to make the loop finite.
We can rewrite the loop the same way, as it's implemented in Dinkumware STL
(it's also fixes the ICE):
---
templateclass _RanIt,
class _Diff,
class _Ty,
class _Pr inline
void _Make_heap(_RanIt _First, _RanIt _Last, _Pr _Pred, _Diff *, _Ty *)
{ // make nontrivial [_First, _Last) into a heap, using _Pred
_Diff _Bottom = _Last - _First;
for (_Diff _Hole = _Bottom / 2; 0 _Hole; )
{ // reheap top half, bottom to top
--_Hole;
std::_Adjust_heap(_First, _Hole, _Bottom,
_Ty(*(_First + _Hole)), _Pred);
}
}
---
-
_EXPORT
template class _RandomAccessIter, class _Compare, class _Dist
void __make_heap (_RandomAccessIter __first, _RandomAccessIter __last,
_Compare __comp, _Dist*)
{
_RWSTD_ASSERT_RANGE (__first, __last);
const _Dist __dist = __last - __first;
for (_Dist __parent = __dist / 2; 0 __parent; ) {
--__parent;
__adjust_heap (__first, __parent, __dist, *(__first + __parent),
__comp);
}
}
-
Farid.
[HP aCC 3.xx on HP-UX/PA-RISC] 20.specialized test fails to compile
The 20.specialized test fails to compile after change in http://svn.apache.org/viewvc?view=revrevision=697885 aCC -c -D_RWSTDDEBUG -mt -I$(TOPDIR)/include -I$(BUILDDIR)/include -I$(TOPDIR)/tests/include -AA -g +d +DD64 +w +W392,655,684,818,819,849 $(TOPDIR)/tests/utilities/20.specialized.cpp Error 746: $(TOPDIR)/include/rw/_specialized.h, line 175 # Cannot use static_cast to convert struct FwdIterY to volatile void *. _RWSTD_STATIC_CAST (volatile void*, *__res); ^^ Error 556: $(TOPDIR)/tests/utilities/20.specialized.cpp, line 140 # Unable to generate specialization FwdIterY std::uninitialized_copyInputIterint,FwdIterY (InputIterint,InputIterint,FwdIterY) due to errors during generation. std::uninitialized_copy (first, last, result); ^ Error 556: $(TOPDIR)/tests/utilities/20.specialized.cpp, line 140 # Unable to generate specialization FwdIterY std::uninitialized_copyInputIterint,FwdIterY (InputIterint,InputIterint,FwdIterY) due to errors during generation. std::uninitialized_copy (first, last, result); ^ gmake: *** [20.specialized.o] Error 2 On the other compilers/platforms this test compiled without errors. Can anyone to look into this issue? Farid.
Re: [PATCH] STDCXX-401 test suite should honor TMPDIR
Hi Scott.
Index: file.cpp
===
--- file.cpp(revision 702657)
+++ file.cpp(working copy)
@@ -208,8 +208,10 @@
#ifndef _RWSTD_NO_MKSTEMP
# define TMP_TEMPLATE tmpfile-XX
+char *tmpdir = getenv (TMPDIR) == NULL ? P_tmpdir : getenv (TMPDIR);
tmpdir might be const char*. And why getenv(TMPDIR) is called twice?
+
if (!buf) {
-static char fname_buf [sizeof (P_tmpdir) + sizeof (TMP_TEMPLATE)];
+static char fname_buf [sizeof (tmpdir) + sizeof (TMP_TEMPLATE)];
Here sizeof (tmpdir) != strlen (tmpdir). I think that using here PATH_MAX is
ok.
[...]
-size_t len = sizeof (P_tmpdir) - 1;
+size_t len = sizeof (tmpdir) - 1;
Same.
Farid.
Nightly testing stalled?
The latest build results on 4.2.x branch generated at Mon Sep 8 15:00:25... Farid.
RE: svn commit: r693419 - /stdcxx/branches/4.3.x/etc/config/xfail.txt
Is there some reason that you didn't just fix the regression shown in STDCXX-1009? Firstly, I found the regression some time later that I commited changes in xfail.txt. Secondly, I want fix the regression and at the same time leave STDCXX-968 fixed :) Can you, please, verify that replacing 1 with 1L don't issues any warnings on 32-bit and 64-bit aCC? Farid.
RE: User-defined compiler flags
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Wednesday, July 02, 2008 6:30 PM To: dev@stdcxx.apache.org Subject: Re: User-defined compiler flags The libc_decl.sh script doesn't using CPPOPTS, CXXOPTS and LDOPTS. make builddir BUILDDIR=mingw15s BUILDTYPE=15s CONFIG=gcc.config CPPOPTS=-mno-cygwin LDOPTS=-mno-cygwin cd mingw15s/include make CPPOPTS=-mno-cygwin LDOPTS=-mno-cygwin But looking into config.log file I see that -mno-cygwin option is not used at configure step. Unless there is some other mechanism that controls this on Windows it seem that it should work. The same behavior on Ubuntu Linux. If you agree, I suggest we open an issue/enhancement as a reminder to implement it. https://issues.apache.org/jira/browse/STDCXX-982 Farid.
RE: Patch for MinGW
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Wednesday, June 25, 2008 7:07 AM To: dev@stdcxx.apache.org Subject: Re: Patch for MinGW Hmm. So the differences are: MinGW _CRITICAL_SECTION InterlockedXxx (long*) Windows _RTL_CRITICAL_SECTION InterlockedXxx (volatile long*) I would be inclined to hardcode the name of the critical section type. I'm less sure about the InterlockedXxx argument. I wouldn't be surprised if MinGW followed in Windows footsteps at some point in the future. If the MinGW maintainers will do that, they could rename _CRITICAL_SECTION as well. :) Have you tried to find out from the maintainers of the project? I've found that they're fixed InterlockedXXX() argument issue in CVS recently: http://sourceforge.net/tracker/index.php?func=detailaid=1996620group_i d=2435atid=102435 So we should recover ATOMIC_OPS.cpp test to support old and new releases of the MinGW. Farid.
RE: Empty member initializers
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Sunday, June 29, 2008 2:13 AM To: dev@stdcxx.apache.org Subject: Re: Empty member initializers From below... _RWSTD_NO_INLINE_MEMBER_TEMPLATES /* not used at all */ This macro shouldn't exist anymore: http://issues.apache.org/jira/browse/STDCXX-339 Looks like Farid forgot to remove the config test (and the text from the README). Yes, it's my fault. Fixed in 4.2.x thus http://svn.apache.org/viewvc?rev=673060view=rev and will be merged into 4.3.x and trunk shortly. Farid.
RE: question on Warning on AIX
-Original Message- From: Jeremy Dean [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2008 7:19 PM To: dev@stdcxx.apache.org Subject: question on Warning on AIX I have a customer that is getting hundrends of warnings like this. The customer is checking to make sure that these are nothing to be concerned about or how to resolve the warnings: /usr/local/rogue/RogueWave/SourcePro/Ed10/include/loc/_num_get.cc, line 126.22: 1540-0840 (W) The integer literal 0x7fffL is out of range. /usr/local/rogue/RogueWave/SourcePro/Ed10/include/streambuf, line 179.25: 1540-0840 (W) The integer literal 0x7fffL is out of range. Perhaps he compiling 32-bit (ILP32) program with using config.h generated for 64-bit (LP64) library? Farid.
RE: remove_reference
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Friday, June 13, 2008 11:04 AM To: dev@stdcxx.apache.org Subject: Re: remove_reference Namespace pollution causes portability problems because of the underspecified contents of standard library headers. stdcxx goes to great lengths to avoid introducing symbols into the std namespace unless required by the standard. For example, while most other implementations expose the contents of cstdio via iostream, stdcxx does not. Similarly, while a number of other implementations expose the contents of (at least) ios when complex or string are #included, stdcxx goes to a lot of trouble to avoid it. This things are good in most cases, except one: the most implementations expose the contents of ios via iomanip, but stdcxx doesn't. So the users have to #include ios manually along with iomanip. But many programmers assumes, that #include iomanip should be enough. In the result there are number or errors like hex is not a member of std, for example when testing boost with stdcxx. Most of this errors are fixed in boost after I creating the issue ticket, but they are appearing in new code! The last one in file, added to the svn by 4 march 2008: http://svn.boost.org/trac/boost/ticket/2004. Farid.
RE: string cow bug ([Fwd: Fwd: Update: string COW])
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Friday, June 13, 2008 7:12 PM To: dev@stdcxx.apache.org Subject: string cow bug ([Fwd: Fwd: Update: string COW]) ...attached is a test case I got from a fellow attendee of my meeting for what at first blush looks like a COW bug in stdcxx string. The expected output on line 4 is: 2. cc1: 'H' 21.3.1 p4: - 4 References, pointers, and iterators referring to the elements of a basic_string sequence may be invalidated by the following uses of that basic_string object: - As an argument to non-member functions swap() (21.3.8.8), operator() (21.3.8.9), and getline() (21.3.8.9). - As an argument to basic_string::swap(). - Calling data() and c_str() member functions. - Calling non-const member functions, except operator[], at, begin, rbegin, end, and rend. - Following construction or any of the above uses, except the forms of insert and erase that return iterators, the first call to non-const member functions operator[], at, begin, rbegin, end, or rend. - The first call on non-const operator[] for s1 object located in s1[0] = 'H'; line. So after that line any references to the elements are invalidated and cc1 should not be used after that line. Farid.
RE: svn commit: r665784 - in /stdcxx/branches/4.2.x: include/ include/rw/ src/ tests/include/
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Tuesday, June 10, 2008 11:00 AM To: dev@stdcxx.apache.org Subject: Re: svn commit: r665784 - in /stdcxx/branches/4.2.x: include/ include/rw/ src/ tests/include/ [EMAIL PROTECTED] wrote: Author: faridz Date: Mon Jun 9 10:13:13 2008 New Revision: 665784 URL: http://svn.apache.org/viewvc?rev=665784view=rev Log: 2008-06-09 Farid Zaripov [EMAIL PROTECTED] Where is the macro _RWSTD_MSVC is #defined? I don't see its definition in this patch and I can't find it anywhere else either. In this patch: http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/include/rw/_config.h? r1=665734r2=665733pathrev=665734 Farid.
Patch for MinGW
I've been working on building stdcxx on MinGW.
Below is patch for review. An option is hardcode
_RWSTD_CRITICAL_SECTION=_CRITICAL_SECTION and
_RWSTD_INTERLOCKED_T=long for MinGW
(_RWSTD_CRITICAL_SECTION=_RTL_CRITICAL_SECTION and
_RWSTD_INTERLOCKED_T=volatile long for MSVC respectively) and don't
recover ATOMIC_OPS.cpp config test.
Suggestions?
ChangeLog:
* etc/config/src/ATOMIC_OPS.cpp: Restored config test file, deleted in
rev. 614212.
Determine type of parameter for InterlockedXXX() function on 32-bit
Windows only.
Determine type of parameter for EnterCriticalSection() and so on
functions.
* include/rw/_mutex.h: Replaced _RTL_CRITICAL_SECTION to
_RWSTD_CRITICAL_SECTION, determined at configure step.
[!_MSC_VER] Added declarations of Win32 API InterlockedXXX()
functions.
[!_MSC_VER] Added inline _InterlockedXXX() functions for consistency
with MSVC's intinsics.
Use __try/__except on MSVC (and ICC/Windows) only.
Index: etc/config/src/ATOMIC_OPS.cpp
===
--- etc/config/src/ATOMIC_OPS.cpp (revision 665767)
+++ etc/config/src/ATOMIC_OPS.cpp (working copy)
@@ -22,7 +22,7 @@
*
**/
-#if defined (_WIN32) !defined (_WIN64)
+#ifdef _WIN32
#include stdio.h
#include windows.h
@@ -30,36 +30,45 @@
extern C {
-typedef int __stdcall pfiipv_t (int*);
-typedef int __stdcall pfiip_t (volatile int*);
typedef long __stdcall pfllp_t (long*);
typedef long __stdcall pfllpv_t (volatile long*);
+struct _CRITICAL_SECTION;
+struct _RTL_CRITICAL_SECTION;
+
+typedef void __stdcall pfvcsp_t (_CRITICAL_SECTION*);
+typedef void __stdcall pfvrcsp_t (_RTL_CRITICAL_SECTION*);
+
} // extern C
-const char* foo (pfiip_t) { return int; }
-const char* foo (pfiipv_t) { return volatile int; }
-
const char* foo (pfllp_t) { return long; }
const char* foo (pfllpv_t) { return volatile long; }
+const char* bar (pfvcsp_t) { return _CRITICAL_SECTION; }
+const char* bar (pfvrcsp_t) { return _RTL_CRITICAL_SECTION; }
+
int main ()
{
+# ifndef _WIN64
// determine the argument type of InterlockedIncrement()
// (the type changes from long* to volatile long* depending
-// on the version/patch of MSVC)
-
+// on the version/patch of PlatformSDK headers)
printf (#define _RWSTD_INTERLOCKED_T %s\n, foo
(InterlockedIncrement));
+# endif // _WIN64
+// determine the argument type of EnterCriticalSection()
+// (the type changes from struct _CRITICAL_SECTION to
+// struct _RTL_CRITICAL_SECTION depending on the version/patch of
+// PlatformSDK headers)
+printf (#define _RWSTD_CRITICAL_SECTION %s\n, bar
(EnterCriticalSection));
+
return 0;
}
#else // not 32-bit Windows
-#include stdio.h
-
int main ()
{
return 0;
Index: include/rw/_mutex.h
===
--- include/rw/_mutex.h (revision 665767)
+++ include/rw/_mutex.h (working copy)
@@ -125,7 +125,7 @@
# ifdef _RWSTD_NO_FWD_DECLARATIONS
#include windows.h
-#define _RWSTD_MUTEX_T _RTL_CRITICAL_SECTION
+#define _RWSTD_MUTEX_T _RWSTD_CRITICAL_SECTION
# else // if defined (_RWSTD_NO_FWD_DECLARATIONS)
@@ -135,20 +135,33 @@
extern C {
// but rather declare these globals here
-struct _RTL_CRITICAL_SECTION;
+struct _RWSTD_CRITICAL_SECTION;
__declspec (dllimport) void __stdcall
-InitializeCriticalSection (_RTL_CRITICAL_SECTION*);
+InitializeCriticalSection (_RWSTD_CRITICAL_SECTION*);
__declspec (dllimport) void __stdcall
-EnterCriticalSection (_RTL_CRITICAL_SECTION*);
+EnterCriticalSection (_RWSTD_CRITICAL_SECTION*);
__declspec (dllimport) void __stdcall
-LeaveCriticalSection (_RTL_CRITICAL_SECTION*);
+LeaveCriticalSection (_RWSTD_CRITICAL_SECTION*);
__declspec (dllimport) void __stdcall
-DeleteCriticalSection (_RTL_CRITICAL_SECTION*);
+DeleteCriticalSection (_RWSTD_CRITICAL_SECTION*);
+#if defined (_RWSTD_INTERLOCKED_T) !defined (_MSC_VER)
+
+__declspec (dllimport) long __stdcall
+InterlockedIncrement (_RWSTD_INTERLOCKED_T*);
+
+__declspec (dllimport) long __stdcall
+InterlockedDecrement (_RWSTD_INTERLOCKED_T*);
+
+__declspec (dllimport) long __stdcall
+InterlockedExchange (_RWSTD_INTERLOCKED_T*, long);
+
+#endif // _RWSTD_INTERLOCKED_T !_MSC_VER
+
} // extern C
_RWSTD_NAMESPACE (__rw) {
@@ -199,15 +212,40 @@
#pragma intrinsic (_InterlockedExchange64)
# endif // _RWSTD_MSVC
#endif // _M_X64
+# elif defined (_RWSTD_INTERLOCKED_T)
+
+inline long _InterlockedIncrement (volatile long *__x)
+{
+return InterlockedIncrement (
+_RWSTD_CONST_CAST (_RWSTD_INTERLOCKED_T*, __x));
+}
+
+inline long _InterlockedDecrement (volatile long *__x)
+{
+return InterlockedDecrement (
+_RWSTD_CONST_CAST (_RWSTD_INTERLOCKED_T*, __x));
+}
+
+inline long
RE: locale failures on Windows (was: Re: [VOTE] stdcxx 4.2.1 release)
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 30, 2008 6:22 PM To: dev@stdcxx.apache.org Subject: locale failures on Windows (was: Re: [VOTE] stdcxx 4.2.1 release) Do we know what the deal is with all the failures (exit status of 4) in the locale tests on Windows XP, Service Pack 2? I've checked the reason of the exit code 4 in licale tests. Two bugs fixed in http://svn.apache.org/viewvc?rev=655967view=rev and http://svn.apache.org/viewvc?rev=656244view=rev After that there two tests still failing with exit code 4: zh_CN.GB18030.bat 40 0.000 0.015 2.515 zh_TW.EUC-TW.bat 40 0.015 0.000 1.015 The problem in exception thrown in convert_sym_to_ucs() from issue_diag(E_UCS) (charmap.cpp, line 655). This exception thrown because of some characters from these charmaps are not fit in 16-bit wchar_t. Perhaps that characters should be ignored... Farid.
RE: ABI test results with MSVC 8.0/Windows XP-64bit/12d
-Original Message- From: Farid Zaripov [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 22, 2008 5:27 AM To: dev@stdcxx.apache.org Subject: ABI test results with MSVC 8.0/Windows XP-64bit/12d msvc 8.0/WinXP-64bit/12d SRC: 4.2.0 4.2.0 4.2.1 4.2.1 LIB: 4.2.0 4.2.1 4.2.0 4.2.1 limits DIFF 0 random_shuffle 0DIFF 21.string.io.stdcxx-250 ABRTNOUT 21.string.stdcxx-231 ABRTNOUT 22.locale.ctype.is331 0 22.locale.ctype.narrow 0 381 5 0 22.locale.num.put 96 24 22.locale.num.put.stdcxx-2 ABRTNOUT 27.basic.ios.copyfmt.stdcxx-766 ABRTNOUT 27.ostream.unformatted.stdcxx-626ABRTNOUT 27.ostream 2 0 2 0 27.streambuf.imbue.stdcxx-307ABRTNOUT 27.stringbuf.overflow.stdcxx-795 ABRTNOUT The results in 15d configuration and on icc 10.0 in 12d and 15d are the same. Farid. I'm curious what it means when nothing is shown in a cell. i.e. what were the results of the limits test for the last two configurations? Actually I have compared the src/lib pairs 4.2.0/4.2.0 vs 4.2.0/4.2.1 only and then 4.2.1/4.2.1 vs 4.2.1/4.2.0 only. So empty cells means that the results has not changed due to replacing the library file. As for the limits example results, I missed that the results has changed. Here the results for limits: msvc 8.0/WinXP-64bit/12d SRC: 4.2.0 4.2.0 4.2.1 4.2.1 LIB: 4.2.0 4.2.1 4.2.0 4.2.1 limits DIFF 0DIFF 0 Farid.
RE: [VOTE] stdcxx 4.2.1 release
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Friday, April 25, 2008 7:45 AM To: dev@stdcxx.apache.org Cc: [EMAIL PROTECTED] Subject: [VOTE] stdcxx 4.2.1 release Please download and test the tarball on a platform of your choice, and send in your vote on this release candidate. In your vote, please identify the platform(s), their versions, and the stdcxx configurations you tested. I tested on 32-bit and 64-bit MSVC 8.0 and ICC 10.0 in 12d/12D build type and also in MSVC 7.1/12d. The results are available here: http://people.apache.org/~faridz/build_msvc-8.0-12d.log http://people.apache.org/~faridz/build_msvc-8.0-x64-12d.log http://people.apache.org/~faridz/build_icc-10.0-12d.log http://people.apache.org/~faridz/build_icc-10.0-x64-12d.log http://people.apache.org/~faridz/build_msvc-7.1-12d.log I have created some new issues for failing tests. My vote is: +1. Farid.
RE: svn commit: r650902 - /stdcxx/trunk/src/num_put.cpp
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Thursday, April 24, 2008 6:02 PM To: dev@stdcxx.apache.org Subject: Re: svn commit: r650902 - /stdcxx/trunk/src/num_put.cpp So let me try to summarize the new behavior: Solaris Windows Other floatX XX double fmt fmt printf long doubleprintf fmt printf Xconverted to double by iostreams fmt formatted using __rw_fmat_infinite(double) printf formatted using sprintf() Did I get it right? Yes, but you missed the column fpclassify (platforms where fpclassify macro is defined). Solaris Windows fpclassify Other floatX X X X double fmt fmtfmt printf long doubleprintf fmt printf printf Btw., is there a test for this other than 22.locale.num.put? It seems, there is no such test. Farid.
Re: svn commit: r650933 - /stdcxx/trunk/src/num_put.cpp
From: Martin Sebor от имени Martin Sebor To: dev@stdcxx.apache.org Subject: Re: svn commit: r650933 - /stdcxx/trunk/src/num_put.cpp URL: http://svn.apache.org/viewvc?rev=650933view=rev Log: 2008-04-23 Farid Zaripov [EMAIL PROTECTED] STDCXX-880 * src/num_put.cpp [_RWSTD_DBL_SIZE == _RWSTD_LDBL_SIZE]: Call double type overload from long double type overload when sizeof (double) == sizeof (long double). What about __rw_fmat_infinite()? Do we need overloads for float and long double or is the conversion from those two types safe (as in doesn't trigger traps or floating exceptions) and adequately efficient? Yes we definitely need overloads of __rw_fmat_infinite(), but in the next release (when we would implement overloads for __rw_isxxx() for corresponding types). Now the only double versions are implemented, but __rw_fmat_infinite() isn't called for float and long double types because of __rw_isfinite() always returns true for float and long double (except the case when sizeof(double) == sizeof (long double)) . Farid.
Re: svn commit: r649647 - /stdcxx/trunk/etc/config/windows/configure.wsf
From: Martin Sebor [mailto:[EMAIL PROTECTED] To: dev@stdcxx.apache.org Subject: Re: svn commit: r649647 - /stdcxx/trunk/etc/config/windows/configure.wsf I'm getting ready to merge a few last minute changes from last week to 4.2.x. I can't tell from the description of this change if this fix is important for 4.2.1 or not. Farid? No. This change might be important for specific platforms, like Windows Mobile. Farid.
ABI test results with MSVC 8.0/Windows XP-64bit/12d
msvc 8.0/WinXP-64bit/12d SRC: 4.2.0 4.2.0 4.2.1 4.2.1 LIB: 4.2.0 4.2.1 4.2.0 4.2.1 limits DIFF 0 random_shuffle 0DIFF 21.string.io.stdcxx-250 ABRTNOUT 21.string.stdcxx-231 ABRTNOUT 22.locale.ctype.is331 0 22.locale.ctype.narrow 0 381 5 0 22.locale.num.put 96 24 22.locale.num.put.stdcxx-2 ABRTNOUT 27.basic.ios.copyfmt.stdcxx-766 ABRTNOUT 27.ostream.unformatted.stdcxx-626ABRTNOUT 27.ostream 2 0 2 0 27.streambuf.imbue.stdcxx-307ABRTNOUT 27.stringbuf.overflow.stdcxx-795 ABRTNOUT The results in 15d configuration and on icc 10.0 in 12d and 15d are the same. Farid.
_RWSTD_NO_BOOL vs _RWSTD_NO_NATIVE_BOOL
In library headers somewhere used _RWSTD_NO_BOOL and somewhere - _RWSTD_NO_NATIVE_BOOL. The _RWSTD_NO_BOOL.is determined at configure step, but _RWSTD_NO_NATIVE_BOOL - not. At the same time _RWSTD_NO_NATIVE_BOOL mentioned in readme file, while _RWSTD_NO_BOOL - doesn't. What the difference between these macros? Shouldn't be _RWSTD_NO_NATIVE_BOOL. replaced with _RWSTD_NO_BOOL.? Farid.
RE: svn commit: r643964 - /stdcxx/trunk/include/rw/_traits.h
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Wednesday, April 02, 2008 7:54 PM To: dev@stdcxx.apache.org Subject: Re: svn commit: r643964 - /stdcxx/trunk/include/rw/_traits.h Thanks for looking into this for me Farid. So Intel C++ on Linux doesn't support these intrinsics at all? I can't find them in the Intel C++ Intrinsics Reference but I thought they were trying to make the compiler 100% compatible with gcc, including all of its extensions. From ICC help: String and Block Copy Intrinsics The following table lists and describes string and block copy intrinsics that you can use across all Intel architectures. The string and block copy intrinsics are not implemented as intrinsics on IA-64 architecture. Intrinsic Description char *_strset(char *, _int32) Sets all characters in a string to a fixed value. int memcmp(const void *cs, const void *ct, size_t n) Compares two regions of memory. Return 0 if csct, 0 if cs=ct, or 0 if csct. void *memcpy(void *s, const void *ct, size_t n) Copies from memory. Returns s. void *memset(void * s, int c, size_t n) Sets memory to a fixed value. Returns s. char *strcat(char * s, const char * ct) Appends to a string. Returns s. int strcmp(const char *, const char *) Compares two strings. Return 0 if csct, 0 if cs=ct, or 0 if csct. char *strcpy(char * s, const char * ct) Copies a string. Returns s. size_t strlen(const char * cs) Returns the length of string cs. int strncmp(char *, char *, int) Compare two strings, but only specified number of characters. int strncpy(char *, char *, int) Copies a string, but only specified number of characters. Farid.
RE: failing regression tests
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Friday, March 28, 2008 10:42 PM To: dev@stdcxx.apache.org Subject: failing regression tests The regression tests below are all failing with SIGABRT. I check the issues and they have all been deferred, so what's missing is an entry for each of these tests in xfail.txt to mark them up on our build result pages. 21.string.assign.stdcxx-629 21.string.insert.stdcxx-630 21.string.insert.stdcxx-632 21.string.replace.stdcxx-170 Farid, I think these are all your issues. Can you please take care of updating xfail.txt when you have a chance? Done. It seems that the 21.string.insert.stdcxx-630 test is added by my mistake (the STDCXX-630 issue is about assign string method and not about insert). So I deleted this test from trunk. Farid.
RE: regression in 23.deque.iterators
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Friday, March 28, 2008 10:54 PM To: dev@stdcxx.apache.org Subject: regression in 23.deque.iterators The 23.deque.iterators test is failing with a SIGABRT. Reverting the most recent changes to deque made to fix STDCXX-635 lets the test pass. Farid, can you please look into it? http://svn.apache.org/viewvc?view=revrevision=637539 Fixed thus: http://svn.apache.org/viewvc?rev=643025view=rev Farid.
RE: svn commit: r641324 - /stdcxx/trunk/tests/regress/21.string.append.stdcxx-438.cpp
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2008 4:29 PM To: [EMAIL PROTECTED] Subject: svn commit: r641324 - /stdcxx/trunk/tests/regress/21.string.append.stdcxx-438.cpp Author: faridz Date: Wed Mar 26 07:29:17 2008 New Revision: 641324 URL: http://svn.apache.org/viewvc?rev=641324view=rev Log: 2008-03-26 Farid Zaripov [EMAIL PROTECTED] * tests/regress/21.string.append.stdcxx-438.cpp: Don't define the replacement operators new and delete on compilers, that can't reliably replace the operators. The 21.string.append.stdcxx-438.cpp regression test failed to link on MSVC 8.0 and later and on ICC/Windows, that using the MSVC 8.0 and later CRT's. This patch is a temporary solution. I tried to find the problem why on MSVC definition of the replacement operators new and delete causing to multiple definition symbol linker error. Actually this problem appears in static builds only, and also MSVC 7.1 doesn't have the any problems with replacement new/delete operators in any builds. But _RWSTD_NO_REPLACEABLE_NEW_DELETE macro is defined in rw/_config-msvcrt for all versions and I think it's not correct. The some digging shows that problem appears when the compiled program uses std::bad_alloc class and the methods of this class is found in our libstdxx.lib and in libcxxx.lib at the same time. In libcxxx.lib the methods of bad_alloc class are located in new.obj along with new and delete operators. But in MSVC headers the methods of bad_alloc class are defined as inline. I don't know why the are also present in libcxxx.lib with external linkage. Maybe due to some special compiler switches or using another header files while the libcxxx.lib being built. If we define the all methods of bad_alloc as inline the new.obj is not used in link process and the program with replacement new/delete operators links successfully. So the question is why we are define the methods of bad_alloc class as not inline? I think we can safely define them as inline (they all are simple enough to inline). An another option is write config test to check if they are inline in compiler headers, then define them inline in out headers. In another case define them as they are defined at the moment. Any thoughts? Farid.
RE: svn commit: r641324 - /stdcxx/trunk/tests/regress/21.string.append.stdcxx-438.cpp
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2008 5:53 PM To: dev@stdcxx.apache.org Subject: Re: svn commit: r641324 - /stdcxx/trunk/tests/regress/21.string.append.stdcxx-438.cpp _RWSTD_NO_REPLACEABLE_NEW_DELETE macro is defined in rw/_config-msvcrt for all versions and I think it's not correct. IIRC, on Windows replacing operator new in one executable (.exe or .dll) doesn't replace it in the other executables (.exe's or .dll's) that the first one links with. That's probably why the macro's #defined, no? Damn, I forgot about this feature of dynamic libraries on Windows. Sure, we can't use the replacement new/delete operators in shared builds on MSVC and ICC/Windows. Farid.
RE: NEW_OFLOW_SAFE config test
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Tuesday, March 25, 2008 3:46 AM To: dev@stdcxx.apache.org Subject: Re: NEW_OFLOW_SAFE config test Eric Lemings wrote: Here's an error compiling the NEW_OFLOW_SAFE.cpp config test: aCC -mt -I. -AA +w +W392 +W655 +W684 +W818 +W819 +W849 +W2193 +W2236 +W2261 +W2340 +W240 1 +W2487 +W4227 +W4229 +W4231 +W4235 +W4237 +W4249 +W4255 +W4272 +W4284 +W4285 +W4286 +W42 96 +W4297 +W3348 -c /amd/devco/lemings/work/stdcxx/trunk.gofish/etc/config/src/NEW_OFLOW_ SAFE.cpp -o NEW_OFLOW_SAFE.o /amd/devco/lemings/work/stdcxx/trunk.gofish/etc/config/src/NEW_OFLOW_ SA FE.cpp, line 46: error #2020: identifier size_t is undefined void* p = ::operator new (size_t (-1)); ^ Shouldn't 'size_t' be replaced with '_RWSTD_SIZE_T'? Or one of the standard headers should be included (e.g. stddef.h, cstddef)? The latter. This regression was introduced here: http://svn.apache.org/viewvc?view=revrevision=634731 Hmm. The NEW_THROWS.cpp before this change also used size_t without including the stddef.h: http://svn.apache.org/viewvc/stdcxx/trunk/etc/config/src/NEW_THROWS.cpp? revision=611451view=markuppathrev=634731 Farid.
RE: svn commit: r638369 - in /stdcxx/trunk/include: loc/_num_get.cc loc/_num_get.h rw/_iosfwd.h
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 19, 2008 6:46 PM
To: dev@stdcxx.apache.org
Subject: Re: svn commit: r638369 - in /stdcxx/trunk/include:
loc/_num_get.cc loc/_num_get.h rw/_iosfwd.h
URL: http://svn.apache.org/viewvc?rev=638369view=rev
Log:
2008-03-18 Farid Zaripov [EMAIL PROTECTED]
* include/loc/_num_get.cc (num_get::get): Code checking
for overflow moved from here...
* include/loc/num_get.h
(_rw_check_overflow_{short|int}): ... to here.
* include/rw/_iosfwd.h: Added new define
_RWSTD_FMTFLAGS (used in _rw_check_overflow_{short|int}).
It occurs to me: is this forward binary compatible? We're
adding a function in this patch, even though it's inline, I
suspect that in debug builds (w/o inlining) this will break
when we replace 4.2.1 with 4.2.0. Have you tested it?
I have tested on MSVC 7.1 and found no problems. The
__rw_check_overflow_{short|int}()
are not exported from library and can't be called directly, only through
num_get::get().
Also I have tested on gcc/Linux and found no problems in forward and
backward compatibility.
Farid.
RE: svn commit: r638369 - in /stdcxx/trunk/include: loc/_num_get.cc loc/_num_get.h rw/_iosfwd.h
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Monday, March 24, 2008 4:41 PM
To: dev@stdcxx.apache.org
Subject: Re: svn commit: r638369 - in /stdcxx/trunk/include:
loc/_num_get.cc loc/_num_get.h rw/_iosfwd.h
Farid Zaripov wrote:
I have tested on MSVC 7.1 and found no problems. The
__rw_check_overflow_{short|int}()
are not exported from library and can't be called directly, only
through num_get::get().
I assume you tested with both debug and optimized shared lib builds.
I tested 15d and 15s builds on both MSVC and gcc.
Let me check the optimized builds also.
Farid.
RE: svn commit: r638382 - in /stdcxx/trunk: include/fstream include/istream src/podarray.h
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Tuesday, March 18, 2008 5:31 PM To: dev@stdcxx.apache.org Subject: Re: svn commit: r638382 - in /stdcxx/trunk: include/fstream include/istream src/podarray.h [EMAIL PROTECTED] wrote: Author: faridz Date: Tue Mar 18 07:22:15 2008 New Revision: 638382 Just out of curiosity: are these warnings new in MSVC 9? (I don't think they show up in MSVC 8 builds.) I saw this warning when compiled the library with MSVC 7.1. Just now compiled with MSVC 8.0 and 9.0 and this warning still present in both compilers. Note: this warning issued on MSVC in strict mode only (when _RWSTD_STRICT_ANSI macro defined). Farid.
RE: svn commit: r638382 - in /stdcxx/trunk: include/fstream include/istream src/podarray.h
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Tuesday, March 18, 2008 6:08 PM To: dev@stdcxx.apache.org Subject: Re: svn commit: r638382 - in /stdcxx/trunk: include/fstream include/istream src/podarray.h Note: this warning issued on MSVC in strict mode only (when _RWSTD_STRICT_ANSI macro defined). Ah! That's why it's not showing up in our nightly builds. Do you think it would be useful to schedule some strict mode builds? Perhaps testing once per week would be useful and enough. By the way there 3 examples along with rwtest library fails to compile in strict mode. Farid.
RE: svn commit: r638369 - in /stdcxx/trunk/include: loc/_num_get.cc loc/_num_get.h rw/_iosfwd.h
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Tuesday, March 18, 2008 6:12 PM To: dev@stdcxx.apache.org Subject: Re: svn commit: r638369 - in /stdcxx/trunk/include: loc/_num_get.cc loc/_num_get.h rw/_iosfwd.h +return = int (_RWSTD_INT_MAX); This looks like a typo (I'm getting a build error). I've tested the patched sources on MSVC and gcc/linux and didn't found this bug due to _RWSTD_INT_MAX == _RWSTD_LONG_MAX on these compilers. Fixed: http://svn.apache.org/viewvc?rev=638433view=rev Farid.
[PATCH] atomic ops on _PA_RISC2_0
Why if _PA_RISC2_0 macro is defined the atimic functions are named
__rw_string_atomic_xxx() but no __rw_atomic_xxx() as on other platforms?
And also why the __rw_string_atomic_pre{in|de}crement(unsigned __x,
bool)
are calling the (possibly undefined?)
__rw_atomic_pre{in|de}crement(int, bool) ?
The proposed patch below:
ChangeLog:
* include/rw/_mutex.h [_PA_RISC2_0]: Rename __rw_string_atomic_xxx()
to __rw_atmic_xxx() respectively.
* include/rw/_defs.h [_PA_RISC2_0]: #define _RWSTD_STRING_ATOMIC_XXX
macros as _RWSTD_ATOMIC_XXX
instead of __rw_string_atomic_xxx().
Index: include/rw/_defs.h
===
--- include/rw/_defs.h (revision 638458)
+++ include/rw/_defs.h (working copy)
@@ -667,26 +667,13 @@
_RWSTD_ATOMIC_SWAP(x, y, mutex)
# endif// _RWSTD_NO_EXT_REENTRANT_IO
-# if defined (_PA_RISC2_0)
+# define _RWSTD_STRING_ATOMIC_PREINCREMENT(x, mutex)\
+ _RWSTD_ATOMIC_PREINCREMENT (x, mutex)
+# define _RWSTD_STRING_ATOMIC_PREDECREMENT(x, mutex)\
+ _RWSTD_ATOMIC_PREDECREMENT (x, mutex)
+# define _RWSTD_STRING_ATOMIC_SWAP(x, y, mutex) \
+ _RWSTD_ATOMIC_SWAP (x, y, mutex)
-#define _RWSTD_STRING_ATOMIC_PREINCREMENT(x, mutex) \
-_RW::__rw_string_atomic_preincrement (x, mutex)
-
-#define _RWSTD_STRING_ATOMIC_PREDECREMENT(x, mutex) \
-_RW::__rw_string_atomic_predecrement (x, mutex)
-
-#define _RWSTD_STRING_ATOMIC_SWAP(x, y, mutex) \
-_RW::__rw_string_atomic_exchange (x, y, mutex)
-
-# else // if !_PA_RISC2_0
-#define _RWSTD_STRING_ATOMIC_PREINCREMENT(x, mutex) \
-_RWSTD_ATOMIC_PREINCREMENT (x, mutex)
-#define _RWSTD_STRING_ATOMIC_PREDECREMENT(x, mutex) \
-_RWSTD_ATOMIC_PREDECREMENT (x, mutex)
-#define _RWSTD_STRING_ATOMIC_SWAP(x, y, mutex) \
-_RWSTD_ATOMIC_SWAP (x, y, mutex)
-# endif // !_PA_RISC2_0
-
// thread-local storage
# ifndef _RWSTD_NO_TLS
#ifndef _RWSTD_THREAD
Index: include/rw/_mutex.h
===
--- include/rw/_mutex.h (revision 638458)
+++ include/rw/_mutex.h (working copy)
@@ -1136,14 +1136,14 @@
inline int
-__rw_string_atomic_preincrement (int __x, bool)
+__rw_atomic_preincrement (int __x, bool)
{
return __rw_atomic_incr32 (__x);
}
inline unsigned
-__rw_string_atomic_preincrement (unsigned __x, bool)
+__rw_atomic_preincrement (unsigned __x, bool)
{
return __rw_atomic_preincrement (_RWSTD_REINTERPRET_CAST(int,
__x),
@@ -1152,14 +1152,14 @@
inline int
-__rw_string_atomic_predecrement (int __x, bool)
+__rw_atomic_predecrement (int __x, bool)
{
return __rw_atomic_decr32 (__x);
}
inline unsigned
-__rw_string_atomic_predecrement (unsigned __x, bool)
+__rw_atomic_predecrement (unsigned __x, bool)
{
return __rw_atomic_predecrement (_RWSTD_REINTERPRET_CAST(int,
__x),
@@ -1168,18 +1168,18 @@
inline int
-__rw_string_atomic_exchange (int __x, int __y, bool)
+__rw_atomic_exchange (int __x, int __y, bool)
{
return __rw_atomic_xchg32 (__x, __y);
}
inline unsigned
-__rw_string_atomic_exchange (unsigned __x, unsigned __y, bool)
+__rw_atomic_exchange (unsigned __x, unsigned __y, bool)
{
-return __rw_string_atomic_exchange (_RWSTD_REINTERPRET_CAST(int,
__x),
-_RWSTD_STATIC_CAST(int,__y),
-false);
+return __rw_atomic_exchange (_RWSTD_REINTERPRET_CAST(int, __x),
+ _RWSTD_STATIC_CAST(int,__y),
+ false);
}
/** i386/gcc || _M_IX86
*/
Farid.
RE: svn commit: r637539 - /stdcxx/trunk/include/deque
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Sunday, March 16, 2008 6:58 AM To: dev@stdcxx.apache.org Subject: Re: svn commit: r637539 - /stdcxx/trunk/include/deque The names pointer1 and pointer2 need to privatized (e.g., _Pointer1). Yes, I forgetting about this all the time. Done thus: http://svn.apache.org/viewvc?rev=637542view=rev Farid.
[PATCH] punct.cpp
The 22.locale.num.put.stdcxx-2 regression test fails on gcc/Linux
(and I suppose that fails on every compiler on non-Windows platform).
The fail is caused when precision is 0, and in this case the precision
is not used in sprintf() format string generated by
__rw_get_stdio_fmat().
As a result the default precision equal to 6 is used.
As I understand the lwg issue 231 resolution, the precision should be
used always for conversions from a floating-point type:
22.2.2.2.2 p5
For conversion from a floating-point type, str .precision() is
specified in the conversion specification.
The proposed patch below:
Index: src/punct.cpp
===
--- src/punct.cpp (revision 631177)
+++ src/punct.cpp (working copy)
@@ -619,9 +619,7 @@
const int fltfld = fmtflags _RWSTD_IOS_FLOATFIELD;
// follows resolution of lwg issue 231
-if ( ( _RWSTD_IOS_FIXED == fltfld
-|| _RWSTD_IOS_SCIENTIFIC == fltfld)
- prec = 0 || prec 0) {
+if (0 = prec) {
// 7.19.6.1, p5 of C99 specifies that, when given using the
// asterisk, negative precision is treated the same as if
Farid.
RE: svn commit: r616003 - /stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 29, 2008 5:56 PM To: dev@stdcxx.apache.org Subject: Re: svn commit: r616003 - /stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp Farid Zaripov wrote: Earlier (http://www.mail-archive.com/[EMAIL PROTECTED]/msg03761. ht ml) I proposed to convert MSVC CRT debug reports along with invalid parameter checking reports to the rw_xxx() reports. I (vaguely) remember discussing this. For the memory errors, I thing rw_error() or even rw_fatal() makes sense. The problem is that these reports may come from different places of MSVC CRT and we couldn't to know what the real reason of concrete report. We get the only the report severity (error, assertion, warning) and the report text. Or we can just print the report message into stderr, to not count these reports as other usual rw_errors and rw_asserts. That would be another option. Although we should probably abort on memory corruption errors. Unfortunately, it's not possible :( Farid.
RE: svn commit: r616003 - /stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 29, 2008 6:27 PM To: dev@stdcxx.apache.org Subject: Re: svn commit: r616003 - /stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 29, 2008 5:56 PM To: dev@stdcxx.apache.org Subject: Re: svn commit: r616003 - /stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp Farid Zaripov wrote: Earlier (http://www.mail-archive.com/[EMAIL PROTECTED]/msg03761. ht ml) I proposed to convert MSVC CRT debug reports along with invalid parameter checking reports to the rw_xxx() reports. I (vaguely) remember discussing this. For the memory errors, I thing rw_error() or even rw_fatal() makes sense. The problem is that these reports may come from different places of MSVC CRT and we couldn't to know what the real reason of concrete report. We get the only the report severity (error, assertion, warning) and the report text. Or we can just print the report message into stderr, to not count these reports as other usual rw_errors and rw_asserts. That would be another option. Although we should probably abort on memory corruption errors. Unfortunately, it's not possible :( Wouldn't the _CrtSetReportHook() function work? http://msdn2.microsoft.com/en-us/library/0yysf5e6(VS.80).aspx I meant that it's not possible to know when we should abort and when only print the message. Farid.
RE: Reply-To for [EMAIL PROTECTED]
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Monday, January 28, 2008 8:03 PM To: dev@stdcxx.apache.org Subject: Reply-To for [EMAIL PROTECTED] The Reply-To address for the issues list is set to [EMAIL PROTECTED] I'm wondering if that's what we want. Shouldn't it be set to dev like the commits list is? Definitely, it's makes sense. If someone wants to write to the issues list, lets post comment on the issue :) Farid.
