RE: svn commit: r662518 - in /stdcxx/branches/4.2.x: tests/containers/23.bitset.cpp tests/containers/23.vector.cons.cpp tests/self/0.printf.cpp tests/support/18.exception.cpp util/collate.cpp util/sca
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Monday, June 02, 2008 5:38 PM
To: dev@stdcxx.apache.org
Subject: Re: svn commit: r662518 - in /stdcxx/branches/4.2.x:
tests/containers/23.bitset.cpp
tests/containers/23.vector.cons.cpp tests/self/0.printf.cpp
tests/support/18.exception.cpp util/collate.cpp util/scanner.cpp
[EMAIL PROTECTED] wrote:
Author: elemings
Date: Mon Jun 2 11:59:24 2008
New Revision: 662518
URL: http://svn.apache.org/viewvc?rev=662518view=rev
Log:
2008-06-02 Eric Lemings [EMAIL PROTECTED]
[...]
Modified: stdcxx/branches/4.2.x/tests/containers/23.vector.cons.cpp
URL:
http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/tests/conta
iners/23.vector.cons.cpp?rev=662518r1=662517r2=662518view=diff
==
---
stdcxx/branches/4.2.x/tests/containers/23.vector.cons.cpp (original)
+++
stdcxx/branches/4.2.x/tests/containers/23.vector.cons.cpp Mon
Jun 2 11:59:24 2008
@@ -618,7 +618,7 @@
for (typename Vector::size_type i = 0; i !=
rw_opt_nloops; ++i) {
// construct an element at then end of array
-alloc.construct (vals + i, i);
+alloc.construct (vals + i, typename
Alloc::value_type (i));
For simplicity (and to avoid running into compiler bugs) I suggest
replacing the typename with:
alloc.construct (vals + i, T (i))
Yep, that would be somewhat better. Those two types are the same
I assume, right?
// verify ctor with a strict InputIterator
InputIterT first (vals, vals, vals + i);
[...]
Modified: stdcxx/branches/4.2.x/tests/support/18.exception.cpp
URL:
http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/tests/suppo
rt/18.exception.cpp?rev=662518r1=662517r2=662518view=diff
==
--- stdcxx/branches/4.2.x/tests/support/18.exception.cpp (original)
+++ stdcxx/branches/4.2.x/tests/support/18.exception.cpp
Mon Jun 2 11:59:24 2008
@@ -668,7 +668,7 @@
// exclude exception, bad_alloc, bad_cast, and
bad_exception
// they are typically generated by the compiler and their
// what() strings are implementation-specific
-unsigned en = j % ((sizeof expect / sizeof *expect) - 5);
+size_t en = j % ((sizeof expect / sizeof *expect) - 5);
The reference to size_t should be qualified with std:: here. I was
about to recommend compiling with EDG eccp again to detect the absence
of the qualification but it appears that #including sys/resource.h
on Linux brings size_t into file scope so compiling with the front
end there doesn't reveal the problem. Ditto for Sun C++ on Solaris
whose C++ C headers are similarly strict.
Yeah, I used the rest of the file as a guide. Some files qualify it,
some don't. I just followed suit.
Brad.
RE: [STDCXX-550] Please peer review this change.
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Monday, June 02, 2008 5:41 PM
To: dev@stdcxx.apache.org
Subject: Re: [STDCXX-550] Please peer review this change.
Eric Lemings wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of
Martin Sebor
Sent: Monday, June 02, 2008 4:21 PM
To: dev@stdcxx.apache.org
Subject: Re: [STDCXX-550] Please peer review this change.
Eric Lemings wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 2:44 PM
To: dev@stdcxx.apache.org
Subject: Re: [STDCXX-550] Please peer review this change.
Eric Lemings wrote:
Would like to get another set of eyes on this before I submit.
$ svn diff include/deque
Index: include/deque
===
--- include/deque (revision 662487)
+++ include/deque (working copy)
@@ -749,7 +749,7 @@
void _C_insert (const iterator __it,
_IntType __n, _IntType __x, int) {
// see 23.1.1, p9 and DR 438
-_C_insert_n (__it, __n, __x);
+_C_insert_n (__it, __n, const_reference (__x));
I suspect this is not correct. Suppose the type of __x is
a 4 byte int and const_reference is an 8 byte long. The cast
will make _C_insert_n() to read 4 bytes past the end of __x.
A better fix might be to cast __x to value_type, as long as
doing so doesn't violate [sequence.reqmts].
Yep. Good call. Will change to value_type() cast.
Do read DR 438 before applying the cast. There are some obscure
corner cases here, e.g., IntType being a user-defined integer-
like type. I don't know if we support this case now, or if we
do, if it's being tested, but suffice it to say that there are
subtle differences between direct-initialization either via
a function-style cast or static_cast, or copy-initialization
(passing arguments to functions).
I did read the DR briefly. Perhaps I should add some conditional
compilation so that __x is converted using value_type() only when
using Sun C++? That would limit the scope of the change and the
issue only relates to this compiler anywho.
I don't think we want to do it differently for different compilers.
Or should I just skip it entirely and leave the warnings as they
are?
That depends on what a small test case looks like. How likely are
users to run into the same warning and what can they do to silence
it? A small test case reproducing the warning should help answer
these questions.
I don't think a test case is really needed. Users can easily encounter
the warnings anytime they use a deque instantiated with 64-bit integer
types as shown by lines 593-601 in file
tests/containers/23.deque.modifiers.cpp where the warnings originally
appeared.
It is just a warning and only for Sun C++ but I see how the explicit
conversion could potentially cause problems. Not likely but possible.
I'll just put it on hold for now.
Brad.
Re: svn commit: r662518 - in /stdcxx/branches/4.2.x: tests/containers/23.bitset.cpp tests/containers/23.vector.cons.cpp tests/self/0.printf.cpp tests/support/18.exception.cpp util/collate.cpp util/sca
Eric Lemings wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Monday, June 02, 2008 5:38 PM
To: dev@stdcxx.apache.org
Subject: Re: svn commit: r662518 - in /stdcxx/branches/4.2.x:
tests/containers/23.bitset.cpp
tests/containers/23.vector.cons.cpp tests/self/0.printf.cpp
tests/support/18.exception.cpp util/collate.cpp util/scanner.cpp
[EMAIL PROTECTED] wrote:
Author: elemings
Date: Mon Jun 2 11:59:24 2008
New Revision: 662518
URL: http://svn.apache.org/viewvc?rev=662518view=rev
Log:
2008-06-02 Eric Lemings [EMAIL PROTECTED]
[...]
Modified: stdcxx/branches/4.2.x/tests/containers/23.vector.cons.cpp
URL:
http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/tests/conta
iners/23.vector.cons.cpp?rev=662518r1=662517r2=662518view=diff
==
---
stdcxx/branches/4.2.x/tests/containers/23.vector.cons.cpp (original)
+++
stdcxx/branches/4.2.x/tests/containers/23.vector.cons.cpp Mon
Jun 2 11:59:24 2008
@@ -618,7 +618,7 @@
for (typename Vector::size_type i = 0; i !=
rw_opt_nloops; ++i) {
// construct an element at then end of array
-alloc.construct (vals + i, i);
+alloc.construct (vals + i, typename
Alloc::value_type (i));
For simplicity (and to avoid running into compiler bugs) I suggest
replacing the typename with:
alloc.construct (vals + i, T (i))
Yep, that would be somewhat better. Those two types are the same
I assume, right?
Yes. Strictly speaking, the template parameter T is redundant. It's
there to avoid having to spell it typename Alloc::value_type and
running into compiler bugs.
[...]
The reference to size_t should be qualified with std:: here. I was
about to recommend compiling with EDG eccp again to detect the absence
of the qualification but it appears that #including sys/resource.h
on Linux brings size_t into file scope so compiling with the front
end there doesn't reveal the problem. Ditto for Sun C++ on Solaris
whose C++ C headers are similarly strict.
Yeah, I used the rest of the file as a guide. Some files qualify it,
some don't. I just followed suit.
Here's the convention:
Tests, examples, and utilities (except for exec) should be using
the new C++ C headers and qualifying all names with std:: (unless
there's a documented reason not to). Those that don't ought to be
changed because the lack of the qualification is most likely a bug.
Library headers avoid #including any C library headers (with the
exception of rw/_traits.h) for namespace cleanliness.
Library sources (including rwtest) #include the deprecated .h
headers to bring in POSIX and other non-C++ and non-C symbols.
Martin
Re: [STDCXX-550] Please peer review this change.
Eric Lemings wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Monday, June 02, 2008 5:41 PM
To: dev@stdcxx.apache.org
Subject: Re: [STDCXX-550] Please peer review this change.
Eric Lemings wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of
Martin Sebor
Sent: Monday, June 02, 2008 4:21 PM
To: dev@stdcxx.apache.org
Subject: Re: [STDCXX-550] Please peer review this change.
Eric Lemings wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 2:44 PM
To: dev@stdcxx.apache.org
Subject: Re: [STDCXX-550] Please peer review this change.
Eric Lemings wrote:
Would like to get another set of eyes on this before I submit.
$ svn diff include/deque
Index: include/deque
===
--- include/deque (revision 662487)
+++ include/deque (working copy)
@@ -749,7 +749,7 @@
void _C_insert (const iterator __it,
_IntType __n, _IntType __x, int) {
// see 23.1.1, p9 and DR 438
-_C_insert_n (__it, __n, __x);
+_C_insert_n (__it, __n, const_reference (__x));
I suspect this is not correct. Suppose the type of __x is
a 4 byte int and const_reference is an 8 byte long. The cast
will make _C_insert_n() to read 4 bytes past the end of __x.
A better fix might be to cast __x to value_type, as long as
doing so doesn't violate [sequence.reqmts].
Yep. Good call. Will change to value_type() cast.
Do read DR 438 before applying the cast. There are some obscure
corner cases here, e.g., IntType being a user-defined integer-
like type. I don't know if we support this case now, or if we
do, if it's being tested, but suffice it to say that there are
subtle differences between direct-initialization either via
a function-style cast or static_cast, or copy-initialization
(passing arguments to functions).
I did read the DR briefly. Perhaps I should add some conditional
compilation so that __x is converted using value_type() only when
using Sun C++? That would limit the scope of the change and the
issue only relates to this compiler anywho.
I don't think we want to do it differently for different compilers.
Or should I just skip it entirely and leave the warnings as they
are?
That depends on what a small test case looks like. How likely are
users to run into the same warning and what can they do to silence
it? A small test case reproducing the warning should help answer
these questions.
I don't think a test case is really needed. Users can easily encounter
the warnings anytime they use a deque instantiated with 64-bit integer
types as shown by lines 593-601 in file
tests/containers/23.deque.modifiers.cpp where the warnings originally
appeared.
I saw the test and the warnings. It's not obvious from the test what
exactly is being instantiated on what type, and there are 82 warnings
in the build logs. It would be a lot easier to talk about if it was
distilled to a few lines of code.
For example, does this produce a warning:
std::dequeint d;
long x = LONG_MAX;
d.insert (d.begin (), x, x);
or does this:
std::dequelong d;
int x = INT_MAX;
d.insert (d.begin (), x, x);
and/or something else...?
It is just a warning and only for Sun C++ but I see how the explicit
conversion could potentially cause problems. Not likely but possible.
I'll just put it on hold for now.
Well, the first case above would lose the high bits of x. Seems like
the warning at the POI would be justified. In the second case I don't
see a need for a warning.
Martin
Re: svn commit: r662614 - /stdcxx/branches/4.2.x/tests/regress/21.c.strings.stdcxx-843.cpp
Eric Lemings wrote:
I just saw this while compiling with Sun C++ 5.9 on Solaris 10:
Thanks. I forgot that we don't use our cxxx headers with this
compiler (or with HP aCC). I need to #include one of our headers.
Martin
CC -c -D_RWSTDDEBUG -mt -I/work/stdcxx/branches/4.2.x/include
-I/build/stdcxx-4.2.x-15D/include
-I/work/stdcxx/branches/4.2.x/tests/include -library=%none -g -m64 +w
-errtags -erroff=hidef
/work/stdcxx/branches/4.2.x/tests/regress/21.c.strings.stdcxx-843.cpp
/work/stdcxx/branches/4.2.x/tests/regress/21.c.strings.stdcxx-843.cpp,
line 57: Error, undefidenterr: _RWSTD_MBSTATE_T_SIZE is not defined.
1 Error(s) detected.
FYI.
Brad.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 7:08 PM
To: [EMAIL PROTECTED]
Subject: svn commit: r662614 -
/stdcxx/branches/4.2.x/tests/regress/21.c.strings.stdcxx-843.cpp
Author: sebor
Date: Mon Jun 2 18:08:15 2008
New Revision: 662614
URL: http://svn.apache.org/viewvc?rev=662614view=rev
Log:
2008-06-02 Martin Sebor [EMAIL PROTECTED]
* tests/regress/21.c.strings.stdcxx-843.cpp: Added a
regression test
for STDCXX-843.
Added:
stdcxx/branches/4.2.x/tests/regress/21.c.strings.stdcxx-843.cp
p (with props)
Added: stdcxx/branches/4.2.x/tests/regress/21.c.strings.stdcxx-843.cpp
URL:
http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/tests/regre
ss/21.c.strings.stdcxx-843.cpp?rev=662614view=auto
==
---
stdcxx/branches/4.2.x/tests/regress/21.c.strings.stdcxx-843.cp
p (added)
+++
stdcxx/branches/4.2.x/tests/regress/21.c.strings.stdcxx-843.cp
p Mon Jun 2 18:08:15 2008
@@ -0,0 +1,68 @@
+/
+ *
+ * 21.c.strings.stdcxx-843.cpp - regression test for STDCXX-843
+ *
+ * http://issues.apache.org/jira/browse/STDCXX-843
+ *
+ * $Id$
+ *
+
**
*
+ *
+ * Licensed to the Apache Software Foundation (ASF) under
one or more
+ * contributor license agreements. See the NOTICE file
distributed
+ * with this work for additional information regarding
copyright
+ * ownership. The ASF licenses this file to you under
the Apache
+ * License, Version 2.0 (the License); you may not use
this file
+ * except in compliance with the License. You may obtain
a copy of
+ * the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in
writing, software
+ * distributed under the License is distributed on an AS
IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
express or
+ * implied. See the License for the specific language
governing
+ * permissions and limitations under the License.
+ *
+
**
/
+
+#include cassert
+#include cwchar
+
+
+// known mbstate_t sizes on major platforms
+#ifdef _RWSTD_OS_AIX
+# define KNOWN_SIZE sizeof(long)
+#elif defined _RWSTD_OS_HP_UX
+# define KNOWN_SIZE 8
+#elif defined _RWSTD_OS_FREEBSD
+# define KNOWN_SIZE 128
+#elif defined _RWSTD_OS_IRIX64
+# define KNOWN_SIZE 1
+#elif defined _RWSTD_OS_LINUX
+# define KNOWN_SIZE 8
+#elif defined _RWSTD_OS_OSF1
+# define KNOWN_SIZE 24
+#elif defined _RWSTD_OS_SUNOS
+# define KNOWN_SIZE (sizeof(long) == 8 ? 32 : 24)
+#elif defined _RWSTD_OS_WINDOWS
+# define KNOWN_SIZE 4
+#endif
+
+
+int main ()
+{
+// verify that the size is the same as what was detectected
+// during configuration
+assert (sizeof (std::mbstate_t) == _RWSTD_MBSTATE_T_SIZE);
+
+#ifdef KNOWN_SIZE
+
+// on known platforms verify that the actual size matches
+// the size known on that platform
+assert (sizeof (std::mbstate_t) == KNOWN_SIZE);
+
+#endif // KNOWN_SIZE
+
+return 0;
+}
Propchange:
stdcxx/branches/4.2.x/tests/regress/21.c.strings.stdcxx-843.cpp
--
svn:eol-style = native
Propchange:
stdcxx/branches/4.2.x/tests/regress/21.c.strings.stdcxx-843.cpp
--
svn:keywords = Id
RE: [jira] Commented: (STDCXX-901) 26.class.gslice test fails
Martin Sebor commented on STDCXX-901:
-
This is from the binary incompatible rewrite of {{valarray}}
that I've been mentioning for eons (I should finally commit it
on trunk). If it fixes this bug it might spark an idea for a
compatible fix...
Martin,
I'm struggling with what appears to a discrepancy between the standard
and the two implementations I'm testing with. According to
lib.gslice.cons, a default constructed slice specifies no elements.
Section lib.class.gslice describes gslices that do have lengths and
strides. The example it gives is shown here
start = 3
length = { 2, 4, 3 }
stride = { 19, 4, 1 }
k = 3 + (0,1) * 19 + (0,1,2,3) * 4 + (0,1,2) * 1
i0, i1, i2, k
(0, 0, 0, 3 ) // = 3 + (0) * 19 + (0) * 4 + (0) * 1
(0, 0, 1, 4 ) // = 3 + (0) * 19 + (0) * 4 + (1) * 1
(0, 0, 2, 5 ) // = 3 + (0) * 19 + (0) * 4 + (2) * 1
(0, 1, 0, 7 ) // = 3 + (0) * 19 + (1) * 4 + (0) * 1
(0, 1, 1, 8 ) // = 3 + (0) * 19 + (1) * 4 + (1) * 1
(0, 1, 2, 9 ) // = 3 + (0) * 19 + (1) * 4 + (2) * 1
(0, 2, 0, 11) // = 3 + (0) * 19 + (2) * 4 + (0) * 1
(0, 2, 1, 12) // = 3 + (0) * 19 + (2) * 4 + (1) * 1
(0, 2, 2, 13) // = 3 + (0) * 19 + (2) * 4 + (2) * 1
(0, 3, 0, 15) // = 3 + (0) * 19 + (3) * 4 + (0) * 1
(0, 3, 1, 16) // = 3 + (0) * 19 + (3) * 4 + (1) * 1
(0, 3, 2, 17) // = 3 + (0) * 19 + (3) * 4 + (2) * 1
(1, 0, 0, 22) // = 3 + (1) * 19 + (0) * 4 + (0) * 1
(1, 0, 1, 23) // = 3 + (1) * 19 + (0) * 4 + (1) * 1
...
(1, 3, 2, 36) // = 3 + (1) * 19 + (3) * 4 + (2) * 1
Assume for a moment that we have the following gslice...
start = 0
length = { 0 }
stride = { 0 }
So the indices specified by this slice should be
k = 0 + () * 0
i0, i1, k
(0, (), 0) // = 0 + () * 0
So this slice should be a view of 0th element in a given array.
I wrote a quick testcase to make sure that I was understanding this
gslice stuff correctly. It creates a valarray and a slice from strings,
then assigns 0 to the resulting gslice_array. This zeros out all
elements specified by the slice. Here is the set of testcases...
int main ()
{
// + length
// |+- stride
// ||
// vv
test ([EMAIL PROTECTED], 0, , );
test ([EMAIL PROTECTED], 0, 0, 0);
test ([EMAIL PROTECTED], 0, 1, 1);
test ([EMAIL PROTECTED], 0, 1, 2);
test ([EMAIL PROTECTED], 0, 1, 3);
test ([EMAIL PROTECTED], 0, 2, 1);
test ([EMAIL PROTECTED], 0, 2, 2);
test ([EMAIL PROTECTED], 0, 3, 3);
test ([EMAIL PROTECTED], 0, 2, 3);
test ([EMAIL PROTECTED], 0, 5, 1);
test ([EMAIL PROTECTED], 1, 5, 1);
test ([EMAIL PROTECTED], 1, 5,2, 1,2);
test ([EMAIL PROTECTED], 0, 0,0,0, 1,2,3);
return 0;
}
And here is the output I get with the Dinkum and gnu implementations...
{1,1,1,1,1,1,1,1,1,1}[0,{},{}] = 0
= = {1,1,1,1,1,1,1,1,1,1}
{1,1,1,1,1,1,1,1,1,1}[0,{0},{0}] = 0
= {1,1,1,1,1,1,1,1,1,1}
{1,1,1,1,1,1,1,1,1,1}[0,{1},{1}] = 0
= {0,1,1,1,1,1,1,1,1,1}
{1,1,1,1,1,1,1,1,1,1}[0,{1},{2}] = 0
= {0,1,1,1,1,1,1,1,1,1}
{1,1,1,1,1,1,1,1,1,1}[0,{1},{3}] = 0
= {0,1,1,1,1,1,1,1,1,1}
{1,1,1,1,1,1,1,1,1,1}[0,{2},{1}] = 0
= {0,0,1,1,1,1,1,1,1,1}
{1,1,1,1,1,1,1,1,1,1}[0,{2},{2}] = 0
= {0,1,0,1,1,1,1,1,1,1}
{1,1,1,1,1,1,1,1,1,1}[0,{3},{3}] = 0
= {0,1,1,0,1,1,0,1,1,1}
{1,1,1,1,1,1,1,1,1,1}[0,{2},{3}] = 0
= {0,1,1,0,1,1,1,1,1,1}
{1,1,1,1,1,1,1,1,1,1}[0,{5},{1}] = 0
= {0,0,0,0,0,1,1,1,1,1}
{1,1,1,1,1,1,1,1,1,1}[1,{5},{1}] = 0
= {1,0,0,0,0,0,1,1,1,1}
{1,1,1,1,1,1,1,1,1,1}[1,{5,2},{1,2}] = 0
= {1,0,0,0,0,0,0,0,1,1}
{1,1,1,1,1,1,1,1,1,1}[0,{0,0,0},{1,2,3}] = 0
= {1,1,1,1,1,1,1,1,1,1}
The STLPort and RW implementations both get stuck in an infinite loop on
the second testcase, so I'm pretty sure that they're broken. I can't
find anything in the standard that says this would be unspecified or
undefined behavior and I don't see anything that calls this out as a
special case. This leads me to believe that this is a bug in both
implementations and I should take it into consideration when applying
any fix.
Travis
RE: [jira] Commented: (STDCXX-901) 26.class.gslice test fails
Okay, I have a fix. It isn't as pretty as I'd like it to be, but it is forward and backward binary compatible. I'm attaching the patch to the issue, which you can find by clicking the link below. Please review when you have a chance. http://issues.apache.org/jira/secure/attachment/12383346/stdcxx-901.patc h Note that I left some commented references to a new inline method gslice::is_empty(). If I submit the fix to 4.2.x I plan to remove these lines. When the fix goes to 4.3.x I'd like to use the clean solution which allows me to eliminate the friendship and direct member access. I also realize that the test is currently incomplete. I will obviously be working to finish up the test before submitting the patch. Travis
RE: [jira] Updated: (STDCXX-955) infinite loop or out of bound access when slicing valarray
Travis Vitek updated STDCXX-955:
Attachment: stdcxx-955.patch
{noformat}
2008-06-03 Travis Vitek [EMAIL PROTECTED]
STDCXX-955
* include/valarray (gslice::ind_numb): Correctly calculate
index count when the length array contains a zero.
* src/valarray.cpp (next_ind): Correctly calculate next index
when the length array contains a zero.
* tests/numerics/26.class.gslice.cpp (make_array): Update to
handle empty strings or other poorly formatted input.
(get_array_size): Correctly calculate index count when the
slice has a size array that contains a zero.
(next_index): Correctly calculate next index when the length
array contains a zero.
(test_gslice): Remove unnecessary linefeed from assertion.
(run_test): Update degenerate testcase to match comment.
{noformat}
So I have one tiny issue with this fix that I should bring up before I
submit it.
The function gslice::ind_numb() is inline and gslice::next_ind() is not.
The functions that use ind_numb() are listed below.
valarrayT::operator[](const gslice) const
valarrayT::valarray(const gslice_arrayT)
valarrayT::operator=(const gslice_arrayT)
The issue is that these functions use ind_numb() to decide how big an
array to allocate, and then they use next_ind() to iterate over those
elements assigning values to each of them. So if ind_numb() returns 4,
but the iteration terminates after just 2 passes, then there would be 2
elements in the array that are probably not supposed to be there.
If the user builds with 4.2.2 headers and links a 4.2.1 library, they
will get the same behavior as they did with 4.2.1. Namely their
application will hang or crash [under conditions from stdcxx-995]
because the gslice iteration code would not contain the fix.
If an application built with 4.2.1 linked the 4.2.2 library it would
also crash, most likely because the allocated array would have 0
elements but the gslice iteration would try to allow multiple elements
to be written. The same app would already crash or hang when linking the
4.2.1 library.
So I'm pretty sure that this change is suitable for 4.2.2 as I can't
envision a scenerio where it would cause any new problems for the user.
Can anyone else? If not I'll submit this change to 4.2.x tomorrow
morning.
Travis
