Re: [jira] Updated: (STDCXX-51) infinity, NaN formatted differently on different platforms
I'm looking at this patch now but it'd be good if someone else
(especially Travis and/or Brad) could spend some time reviewing
it too. The goal here is to eventually provide implementations
for these functions (or similar) on all platforms.
Thanks
Martin
Farid Zaripov (JIRA) wrote:
[
https://issues.apache.org/jira/browse/STDCXX-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov updated STDCXX-51:
Attachment: num_put.diff
The proposed patch attached.
ChangeLog:
* src/num_put.cpp (__rw_isinfnan): New function to detect inf and nan values.
(__rw_isinf): New function to detect inf values.
(__rw_isneginf): New function to detect negative inf values.
(__rw_isnan): New function to detect nan values.
(__rw_isnegnan): New function to detect negative nan values.
(__rw_isqnan): New function to detect quiet nan values.
(__rw_issnan): New function to detect signaling nan values.
(__rw_fmat_infnan): New function to format inf and nan values.
(__rw_put_num): Use __rw_isinfnan() and __rw_fmat_infnan() to format inf and
nan values.
infinity, NaN formatted differently on different platforms
--
Key: STDCXX-51
URL: https://issues.apache.org/jira/browse/STDCXX-51
Project: C++ Standard Library
Issue Type: Improvement
Components: 22. Localization
Affects Versions: 4.1.2
Environment: all
Reporter: Martin Sebor
Assignee: Farid Zaripov
Priority: Minor
Attachments: num_put.diff
The output of the program below is different depending on the operating system
it runs on. It should be the same (preferably like that on AIX).
$ cat u.cpp && uname -sr && make u -r && ./u
#include
#include
int main ()
{
std::cout << std::numeric_limits::infinity () << '\n'
<< std::numeric_limits::quiet_NaN () << '\n'
<< std::numeric_limits::signaling_NaN () << '\n';
}
SunOS 5.9
gcc -c -I/build/sebor/dev/stdlib/include/ansi -D_RWSTDDEBUG -pthreads
-D_RWSTD_USE_CONFIG -I/build/sebor/gcc-3.4.3-15s/include
-I/build/sebor/dev/stdlib/include -I/build/sebor/dev/stdlib/examples/include
-pedantic -nostdinc++ -g -Wall -W -Wcast-qual -Winline -Wshadow
-Wwrite-strings -Wno-long-long u.cpp
gcc u.o -o u -pthreads -L/build/sebor/gcc-3.4.3-15s/lib -lstd15s -lsupc++ -lm
rm u.o
inf
nan
nan
$ uname -vs && gmake u -r && ./u
AIX 5
xlCcore_r -c -I/build/sebor/dev/stdlib/include/ansi -D_RWSTDDEBUG
-D_RWSTD_USE_CONFIG -I/build/sebor/vacpp-7.0.0.3-15D/include
-I/build/sebor/dev/stdlib/include -I/build/sebor/dev/stdlib/examples/include
-g -q64 -qtemplateregistry=u.ti u.cpp
xlCcore_r u.o -o u -I/build/sebor/dev/stdlib/include/ansi -D_RWSTDDEBUG
-D_RWSTD_USE_CONFIG -liconv -brtl -q64 -I/build/sebor/dev/stdlib/include/ansi
-D_RWSTDDEBUG-D_RWSTD_USE_CONFIG -I/build/sebor/vacpp-7.0.0.3-15D/include
-I/build/sebor/dev/stdlib/include -I/build/sebor/dev/stdlib/examples/include
-qtemplateregistry=u.ti -L/build/sebor/vacpp-7.0.0.3-15D/lib -lstd15D -lm
rm u.o
inf
nanq
nans
Re: svn commit: r643120 - /stdcxx/trunk/util/output.cpp
Andrew, we're getting a bunch of new signed/unsigned comparison
warnings after this change. Can you look into silencing them when
you have a minute?
$TOPDIR/util/output.cpp: In function ‘bool rbinit(readback*, FILE*)’:
$TOPDIR/util/output.cpp:88: warning: comparison between signed and
unsigned integer expressions
$TOPDIR/util/output.cpp:96: warning: comparison between signed and
unsigned integer expressions
$TOPDIR/util/output.cpp: In function ‘char rbgetc(readback*)’:
$TOPDIR/util/output.cpp:160: warning: comparison between signed and
unsigned integer expressions
$TOPDIR/util/output.cpp:164: warning: comparison between signed and
unsigned integer expressions
$TOPDIR/util/output.cpp:176: warning: comparison between signed and
unsigned integer expressions
$TOPDIR/util/output.cpp:179: warning: comparison between signed and
unsigned integer expressions
Thanks
Martin
[EMAIL PROTECTED] wrote:
Author: ablack
Date: Mon Mar 31 13:03:58 2008
New Revision: 643120
URL: http://svn.apache.org/viewvc?rev=643120&view=rev
Log:
2008-03-31 Andrew Black <[EMAIL PROTECTED]>
STDCXX-426
* util/output.cpp (struct readback): Add convenience data structure
for backwards file reading.
(rbinit): Add method to initialize structure.
(rbbof): Add method to check if structure points to the beginning
of a file.
(rbsync): Add method to synchronize the file handle the structure
is built on to the structure.
(rbgetc): Add method to retrieve a character from the file and
move the structure one position closer to the start
(rbscanf): Add methods to search for a string using the
structure, possibly capturing an unsigned integer in the process.
(check_test, check_compat_test): Alter to use above methods.
Modified:
stdcxx/trunk/util/output.cpp
Modified: stdcxx/trunk/util/output.cpp
URL:
http://svn.apache.org/viewvc/stdcxx/trunk/util/output.cpp?rev=643120&r1=643119&r2=643120&view=diff
==
--- stdcxx/trunk/util/output.cpp (original)
+++ stdcxx/trunk/util/output.cpp Mon Mar 31 13:03:58 2008
@@ -44,6 +44,239 @@
# define ENOENT 2
#endif /* ENOENT */
+/**
+ Arbitrary constant controling static read buffer size.
+
+ @see check_example ()
+ @see rbread ()
+*/
+#define DELTA_BUF_LEN 64
+
+/**
+This structure is used to encapsulate the data involved in a backwards
+file read.
+*/
+struct readback {
+FILE* src;
+char buf[DELTA_BUF_LEN];
+long bpos;
+};
+
+/**
+ Initializes the provided readback structure, with the provided file
+ handle.
+
+ @param rb pointer to readback structure to initialize
+ @param src file handle to initialize rb with.
+ @returns true if successfully initialized, false otherwise.
+*/
+static bool
+rbinit (struct readback* rb, FILE* const src)
+{
+const size_t buflen = sizeof rb->buf;
+long fpos;
+assert (0 != rb);
+assert (0 != src);
+
+rb->src = src;
+if (-1 == fseek (rb->src, 0, SEEK_END))
+return false;
+fpos = ftell (rb->src);
+if (-1 == fpos)
+return false;
+
+if (fpos <= buflen)
+rb->bpos = fpos;
+else
+rb->bpos = buflen;
+
+if (-1 == fseek (rb->src, fpos - rb->bpos, SEEK_SET))
+return false;
+
+return rb->bpos == fread (rb->buf, 1, rb->bpos, rb->src);
+}
+
+/**
+ This method is semi-analagous to feof.
+
+ @param rb pointer to readback structure to check begin-of-file state for
+ @returns true if structure points to the begining of the file, false
+ otherwise
+*/
+static bool
+rbbof (const struct readback* const rb)
+{
+assert (0 != rb);
+assert (0 != rb->src);
+return (0 == rb->bpos) && (0 == ftell (rb->src));
+}
+
+/**
+ Syncronizes the file handle underlying a readback structure to the
+ pointer in the structure. This method is called if you wish to start
+ reading forward from the current point in the readback structure.
+
+ @param rb pointer to the readback structure to syncronize.
+ @return true if the structure was successfully syncronized, false
+ otherwise.
+*/
+static bool
+rbsync (struct readback* const rb)
+{
+assert (0 != rb);
+assert (0 != rb->src);
+const size_t buflen = sizeof rb->buf;
+long fpos = ftell (rb->src) - buflen;
+if (0 > fpos)
+fpos=0;
+fpos += rb->bpos;
+rb->bpos=0;
+
+return -1 != fseek (rb->src, fpos, SEEK_SET);
+}
+
+/**
+ Updates the provided readback structure, returning the last unread
+ character in the file. This method is semi-analagous to fgetc.
+
+ @param rb pointer to readback structure to read from.
+ @return EOF if beginning of file or I/O error, read character
+ otherwise.
+*/
+static char
+rbgetc (struct readback* rb)
+{
+const size_t buflen = sizeof rb->buf;
+assert (0 != rb);
+assert (0 != rb->src);
+if (!rb->bpos) {
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. Martin [EMAIL PROTECTED] wrote: Author: faridz Date: Wed Apr 2 09:35:26 2008 New Revision: 643964 URL: http://svn.apache.org/viewvc?rev=643964&view=rev Log: 2008-04-02 Farid Zaripov <[EMAIL PROTECTED]> STDCXX-799 * include/rw/_traits.h: Don't use gcc string builtins on icc. Modified: stdcxx/trunk/include/rw/_traits.h Modified: stdcxx/trunk/include/rw/_traits.h URL: http://svn.apache.org/viewvc/stdcxx/trunk/include/rw/_traits.h?rev=643964&r1=643963&r2=643964&view=diff == --- stdcxx/trunk/include/rw/_traits.h (original) +++ stdcxx/trunk/include/rw/_traits.h Wed Apr 2 09:35:26 2008 @@ -85,7 +85,7 @@ # define _RWSTD_WCSLEN_RW::__rw_wcslen #else // if !defined (_RWSTDDEBUG) && !defined (_RWSTD_EDG_ECCP) -# if 4 <= __GNUG__ +# if 4 <= __GNUG__ && !defined (__INTEL_COMPILER) // use gcc 4.x intrinsic functions #define _RWSTD_MEMCPY__builtin_memcpy #define _RWSTD_MEMCMP__builtin_memcmp
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 cs0 if cs>ct. 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 cs0 if cs>ct. 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: svn commit: r643964 - /stdcxx/trunk/include/rw/_traits.h
Farid Zaripov wrote: -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: I've read the Intel C++ manuals. They don't mention __builtin_memcpy either but the compiler seems to understand it just fine. In fact, the latest compiler understands all the gcc intrinsics with the exception of __builtin_memmove. So perhaps disabling just that one builtin would be enough. Martin 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 cs0 if cs>ct. 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 cs0 if cs>ct. 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: 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 8:38 PM > To: dev@stdcxx.apache.org > Subject: Re: svn commit: r643964 - /stdcxx/trunk/include/rw/_traits.h > > Farid Zaripov wrote: > > From ICC help: > > I've read the Intel C++ manuals. They don't mention > __builtin_memcpy either but the compiler seems to understand > it just fine. In fact, the latest compiler understands all > the gcc intrinsics with the exception of __builtin_memmove. > So perhaps disabling just that one builtin would be enough. Ok, but why we need to use __builtin_xxx() functions instead of corresponding std::xxx() functions while both set of these functions are intrinsics on icc? :) Farid.
Re: [jira] Commented: (STDCXX-742) [IBM XLC++ 9.0/AIX 5.3] 22.locale.messages fails with assertions
Travis Vitek wrote:
Martin Sebor wrote:
Travis Vitek wrote:
Travis Vitek commented on STDCXX-742:
-
This is happening because we don't use the -qrtti=dynamiccast
option. We internally use a dynamic_cast to determine if the
facet is of the correct derived type, but if dynamic_cast
isn't supported we use a C style cast, and that returns bad results.
This case is essentially the same as STDCXX-664. We didn't add
-qrtti=dynamiccast back then, and we just worked around the
issue in the test. It seems to me that we should have added
the flag. Would this be a binary compatible change?
What are the thoughts on this? There was some discussion
[http://tinyurl.com/3xfdma] of enabling -qrtti=dynamiccast for the
VisualAge C++ compiler, but it petered out.
Is there any way to turn on rtti using a pragma? That way we could
enable it only for translation units that included and we
wouldn't be shoving the option down the throats of users who don't
care about named locales.
No, there is no pragma for this. Even if there were we would need to do
some hacking to get it to work. We try determine if dynamic_cast<>()
exists and is functioning correctly at configuration time. If that
config test fails, we define _RWSTD_NO_DYNAMIC_CAST. So even if we
managed to enable rtti when was included, we would need to
'fix' the _RWSTD_NO_DYNAMIC_CAST and _RWSTD_DYNAMIC_CAST macros. Ewww..
Or just add a special implementation just for XLC++. But sounds
like that's not possible anyway.
Btw., does XLC++ itself correctly handle the test case mentioned
in the thread, even without -qrtti? (It's possible to get some
simple cases to work even w/o the option but not all of them).
I'm not absolutely sure what you're asking. It sounds like you are
asking if the Standard C++ Library implementation that ships with XLC++
has this same problem.
That's exactly what I was asking, thanks.
The answer to that is no...
I wonder if it would get this right:
struct MyMessages: std::messages { };
assert (!std::has_facet(std::locale::classic ()));
If not, they probably have their own simple version of "RTTI" built
into the facet (e.g., via a virtual function) but they still can't
handle tricky cases like this one. Unfortunately, we can't even do
this much w/o breaking binary compatibility.
All in all, I'm still not sure this fairly obscure corner case is
worth the effort of adding a compiler option for. C++ locales are
used by only a small community of users, and I suspect that this
case (calling has_facet or use_facet with a facet derived from one
of the standard ones) is unlikely to come up even in their "advanced"
uses. I say we open an issue for this just for the record and keep
deferring it until we feel like adding the option or until IBM
decides to enable RTTI by default.
Martin
$ type t.cpp
#include
#include
#include
template
void test_has_facet (const char *loc_name, const char *cname)
{
const std::locale loc =
loc_name ? std::locale (loc_name) : std::locale ();
typedef std::messages_byname ByName;
const bool byname = loc_name
&& std::strcmp (loc_name, "C");
const bool facet_exists = std::has_facet(loc);
assert (byname == facet_exists);
try {
// verify that use facet throws an exception only
// for the default and "C" locales
std::use_facet(loc);
assert (byname);
}
catch (std::exception &ex) {
assert (!byname);
}
}
template
void test_messages (charT, const char *cname)
{
// exercise has_facet and use_facet in the default locale
test_has_facet(0, cname);
// exercise has_facet and use_facet in locale("C")
test_has_facet("C", cname);
}
int main (int, char*[])
{
test_messages (char (), "char");
return 0;
}
$ xlC t.cpp -o t && ./t
$
If I run the same code under stdcxx, I get the following
$ gmake t && ./t
Assertion failed: byname == facet_exists, file t.cpp, line 18
IOT/Abort trap (core dumped)
$
Travis
Re: svn commit: r643964 - /stdcxx/trunk/include/rw/_traits.h
Farid Zaripov wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Wednesday, April 02, 2008 8:38 PM
To: dev@stdcxx.apache.org
Subject: Re: svn commit: r643964 - /stdcxx/trunk/include/rw/_traits.h
Farid Zaripov wrote:
From ICC help:
I've read the Intel C++ manuals. They don't mention
__builtin_memcpy either but the compiler seems to understand
it just fine. In fact, the latest compiler understands all
the gcc intrinsics with the exception of __builtin_memmove.
So perhaps disabling just that one builtin would be enough.
Ok, but why we need to use __builtin_xxx() functions instead of
corresponding std::xxx()
functions while both set of these functions are intrinsics on icc? :)
That's a good question. Intel C++ 10 generates different code
for each, so we should probably do some benchmarking before we
switch from one to the other.
For this program:
#include
void foo (char *s, size_t n) { memset (s, 0, n); }
void bar (char *s, size_t n) { __builtin_memset (s, 0, n); }
Intel C++ 10.1 generates this code at -O2:
foo:
pushl 8(%esp)
pushl $0
pushl 12(%esp)
call _intel_fast_memset
addl $12, %esp
ret
bar:
pushl %edi
pushl %esi
xorl %eax, %eax
movl 12(%esp), %edi
movl 16(%esp), %ecx
andl $65535, %eax
movb %al, %ah
movl %ecx, %esi
movl %eax, %edx
shll $16, %eax
shrl $2, %ecx
orl %edx, %eax
rep
stosl
movl %esi, %ecx
andl $3, %ecx
rep
stosb
popl %esi
popl %edi
ret
Martin
nightly build errors 4/2/08
Some platforms are going to show up as ERROR / DATA today and tomorrow due to code changes in the infrastructure. This issue is being looked at and hopefully be fix by today.
RE: spaces in rw_xxx_expand()
>Martin Sebor wrote:
>
>PING? Should I open an issue for this or is it something you're
>already working on or planning to?
>
Well if we want 100% compatibility with the shell, then it should be
implemented. I took a look, and I think I can fix it by modifying
_rw_brace_graph::brace_expand_write() to treat quoted blocks literally
and failing if an unescaped quote isn't matched. That will break
rw_brace_expand(), but that isn't too big of a deal as we've discussed
removing that function several times.
Would you please open an issue for this? I would have done this myself,
but I'm not sure how high a priority this is for you. I'm assuming that
this is not to serious because you should be able to work around it by
using escapes.
>
>Martin Sebor wrote:
>>
>> In the shell, spaces that are otherwise treated as separators can
>> be either escaped or quoted to have them interpreted as ordinary
>> characters. The rw_xxx_expand() functions let me escape spaces but
>> they don't seem to like quoting. For example, the shell expands
>> the following three strings to the same result:
>>
>> "a{b\ c,d}"==> "ab c ad"
>> "a{b' 'c,d}"
>> "a{b" "c,d}"
>>
>> but rw_brace_expand() fails on the last two. It should work the
>> same as the shell.
>>
>> In the change below I've enhanced the 0.braceexpand.cpp test to
>> exercise a number of (passing) test cases including plan as well
>> as escaped whitespace:
>>
>> http://svn.apache.org/viewvc?rev=642790&view=rev
>>
>> I think the same test cases should be added for quoted whitespace.
>>
>> Martin
>>
>>
RE: svn commit: r642397 - in /stdcxx/trunk/tests/src: braceexp.cpp locale.cpp
>Martin Sebor wrote: > >Great, that fixes locale.cpp. Thanks for doing that. I was also >(or mainly) pointing out the same problems in braceexp.cpp. I >hesitate to commit a fix myself in case you're working on the >file but here's a patch that addresses the remaining problems: > Martin, Your patch looks fine to me. Feel free to apply it.
The quintessential STDCXX test is...?
Hey, If you had to point to one single test program in the STDCXX test suite as a model for writing all other STDCXX tests, which one would it be? Thanks, Brad.
RE: [PATCH] STDCXX-423 LIMITS.cpp assumes integers with no padding bits
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Saturday, March 22, 2008 4:47 PM
> To: dev@stdcxx.apache.org
> Subject: Re: [PATCH] STDCXX-423 LIMITS.cpp assumes integers with no
> padding bits
>
> Sorry Scott, I'm still not sure this is completely correct.
>
> According to 7.18.1.1 of C99, "The typedef name intN_t designates
> a signed integer type with width N, no padding bits, and a two's
> complement representation."
>
> Can you point me to the part of the patch that checks that each
> of the exact-width types has no padding bits and that it uses
> a two's complement representation?
>
> A few more comments are inline...
>
> Scott Zhong wrote:
> > Index: LIMITS.cpp
> > ===
> > --- LIMITS.cpp (revision 638996)
> > +++ LIMITS.cpp (working copy)
> > @@ -223,7 +223,19 @@
> > return bits;
> > }
> >
> > +template
> > +unsigned compute_type_bits()
> > +{
> > +T max = T (one);
> > +T current = T(one);
> > +int bits = 1;
> >
> > +for (; T (current * 2) > max; current *=2, max *= 2, bits++) {
}
> > +
> > +return bits;
> > +}
>
> This function computes the number of bits in the value representation
> of the type T. We also need to compute the number of bits in the
object
> representation of the type (i.e., sizeof(T) * CHAR_BIT). Only if the
> two match, and when (no_twos_complement == 0) holds can we define
> the exact-width types.
>
> > +
> > +
> > // used to compute the size of a pointer to a member function
> > struct EmptyStruct { };
> >
> > @@ -397,6 +409,12 @@
> > // 1 for a 16-bit integer, etc)
> > int width_bits = 0;
> >
> > +// store exact bit size of each type
> > +int ushort_bits = compute_type_bits ();
> > +int uint_bits = compute_type_bits ();
> > +int ulong_bits = compute_type_bits ();
> > +int ullong_bits = compute_type_bits ();
>
> The last line needs to be guarded in case long long is not
> recognized as a type (e.g., EDG eccp in strict mode).
>
> Martin
>
Martin, the macro LLong already takes care of this.
Re: The quintessential STDCXX test is...?
Eric Lemings wrote:
Hey,
If you had to point to one single test program in the STDCXX test suite
as a model for writing all other STDCXX tests, which one would it be?
They're all very different, depending on what they exercise and who
wrote them.
IMO, think the 22.locale.{money,num,time}.{get,put}.cpp tests are clean
and easy enough to work with.
Some of the container and strings tests are very good at exhaustively
exercising the respective member functions, including exception safety,
but I find them more difficult to follow (there's quite a bit of
infrastructure in the driver that they all share).
Then there are all the regression tests, most of which are he pinnacle
of simplicity.
Martin
Re: svn commit: r642397 - in /stdcxx/trunk/tests/src: braceexp.cpp locale.cpp
Travis Vitek wrote: Martin Sebor wrote: Great, that fixes locale.cpp. Thanks for doing that. I was also (or mainly) pointing out the same problems in braceexp.cpp. I hesitate to commit a fix myself in case you're working on the file but here's a patch that addresses the remaining problems: Martin, Your patch looks fine to me. Feel free to apply it. I ended up checking in a slightly more extensive change to also replace all occurrences of _RWSTD_SIZE_T with plain size_t for readability. http://svn.apache.org/viewvc?rev=644098&view=rev Martin
RE: [jira] Commented: (STDCXX-811) [Solaris Threads] SIGSEGV in 22.locale.statics.mt.cpp
file stdcxx/trunk/src/locale_global.cpp:
...
56 setlocale (_RWSTD_LC_ALL, rhs.name ().c_str ());
...
setlocale() is not a MTS function, is it? From what I see,
it looks like std::locale::global() is being called from
two threads with the same rhs object.
>From the Solaris setlocale(3C) man page:
"NOTES
It is unsafe for any thread to change locale (by calling
setlocale() with a non-null locale argument) in a mul-
tithreaded application while any other thread in the appli-
cation is using any locale-sensitive routine. To change
locale in a multithreaded application, setlocale() should be
called prior to using any locale-sensitive routine. Using
setlocale() to query the current locale is safe and can be
used anywhere in a multithreaded application except when
some other thread is changing locale."
Brad.
> -Original Message-
> From: Eric Lemings (JIRA) [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 02, 2008 4:39 PM
> To: Eric Lemings
> Subject: [jira] Commented: (STDCXX-811) [Solaris Threads]
> SIGSEGV in 22.locale.statics.mt.cpp
>
>
> [
> https://issues.apache.org/jira/browse/STDCXX-811?page=com.atla
> ssian.jira.plugin.system.issuetabpanels:comment-tabpanel&focus
> edCommentId=12584863#action_12584863 ]
>
> Eric Lemings commented on STDCXX-811:
> -
>
> Here's a stack trace where the test is failing, just for the record.
>
> {noformat}
> [EMAIL PROTECTED] tests]$ dbx ./22.locale.statics.mt core
> For information about new features see `help changes'
> To remove this message, put `dbxenv suppress_startup_message
> 7.6' in your .dbxrc
> Reading 22.locale.statics.mt
> dbx: warning: core object name "22.locale.stati" matches
> object name "22.locale.statics.mt" within the limit of 14.
> assuming they match
> core file header read successfully
> Reading ld.so.1
> ...
> Reading [EMAIL PROTECTED]
> [EMAIL PROTECTED] ([EMAIL PROTECTED]) terminated by signal SEGV (no mapping
> at the fault address)
> 0x7f60dbb8: defrag+0x0078: ld [%g5 + 16], %o5
> Current function is std::locale::global
>56 setlocale (_RWSTD_LC_ALL, rhs.name ().c_str ());
> (dbx) where
> current thread: [EMAIL PROTECTED]
> [1] defrag(0x5920, 0x59200160,
> 0x7f72cb18, 0x59200010, 0x592000e0,
> 0x4f383835392d3520), at 0x7f60dbb8
> [2] get_lcinterface(0x7f72c1b8, 0x7f72c370,
> 0x7e3fb708, 0x0, 0x2000, 0x7f627728), at
> 0x7f60e1b8
> [3] informrtld(0x21e0, 0x2000, 0x7e95e988,
> 0x7eae6000, 0x158954, 0x101010101010101), at
> 0x7e98d6fc
> [4] _setlocale(0x7c9052f0, 0x7e9dbc7e, 0x6,
> 0x7c905230, 0x2000, 0x7eaf00b0), at 0x7e98d458
> =>[5] std::locale::global(rhs = STRUCT), line 56 in
> "locale_global.cpp"
> [6] test_global(_ARG1 = 0x7fffe9b8), line 95 in
> "22.locale.statics.mt.cpp"
> (dbx)
> {noformat}
>
>
> > [Solaris Threads] SIGSEGV in 22.locale.statics.mt.cpp
> > -
> >
> > Key: STDCXX-811
> > URL:
> https://issues.apache.org/jira/browse/STDCXX-811
> > Project: C++ Standard Library
> > Issue Type: Bug
> > Components: 22. Localization
> >Affects Versions: 4.2.0
> >Reporter: Martin Sebor
> >Assignee: Eric Lemings
> >Priority: Critical
> > Fix For: 4.2.1
> >
> > Original Estimate: 4h
> > Time Spent: 1h
> > Remaining Estimate: 3h
> >
> > Regardless of the compiler (gcc or Sun C++), when compiled
> with Solaris Threads instead of POSIX threads, the
> [22.locale.statics.mt|http://svn.apache.org/repos/asf/stdcxx/t
> runk/tests/localization/22.locale.statics.mt.cpp] fails at
> runtime with SIGSEGV or SIGHUP, suggesting a problem with the
> uses of Solaris threads mutexes in the library.
> > I'm assuming this is not a regression but we need to check
> the results of the test in 4.2.0 to make sure. If it is one,
> it would make the priority of this issue a Blocker.
> Otherwise, if it's not a new problem, we might be able to
> defer it post 4.2.1 if it's too hard to fix.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
Re: [jira] Commented: (STDCXX-811) [Solaris Threads] SIGSEGV in 22.locale.statics.mt.cpp
Eric Lemings wrote:
file stdcxx/trunk/src/locale_global.cpp:
...
56 setlocale (_RWSTD_LC_ALL, rhs.name ().c_str ());
...
setlocale() is not a MTS function, is it? From what I see,
it looks like std::locale::global() is being called from
two threads with the same rhs object.
You're right, that does look like a bug in our library. We should
guard the call to setlocale().
Martin
From the Solaris setlocale(3C) man page:
"NOTES
It is unsafe for any thread to change locale (by calling
setlocale() with a non-null locale argument) in a mul-
tithreaded application while any other thread in the appli-
cation is using any locale-sensitive routine. To change
locale in a multithreaded application, setlocale() should be
called prior to using any locale-sensitive routine. Using
setlocale() to query the current locale is safe and can be
used anywhere in a multithreaded application except when
some other thread is changing locale."
Brad.
-Original Message-
From: Eric Lemings (JIRA) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 02, 2008 4:39 PM
To: Eric Lemings
Subject: [jira] Commented: (STDCXX-811) [Solaris Threads]
SIGSEGV in 22.locale.statics.mt.cpp
[
https://issues.apache.org/jira/browse/STDCXX-811?page=com.atla
ssian.jira.plugin.system.issuetabpanels:comment-tabpanel&focus
edCommentId=12584863#action_12584863 ]
Eric Lemings commented on STDCXX-811:
-
Here's a stack trace where the test is failing, just for the record.
{noformat}
[EMAIL PROTECTED] tests]$ dbx ./22.locale.statics.mt core
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message
7.6' in your .dbxrc
Reading 22.locale.statics.mt
dbx: warning: core object name "22.locale.stati" matches
object name "22.locale.statics.mt" within the limit of 14.
assuming they match
core file header read successfully
Reading ld.so.1
...
Reading [EMAIL PROTECTED]
[EMAIL PROTECTED] ([EMAIL PROTECTED]) terminated by signal SEGV (no mapping at
the fault address)
0x7f60dbb8: defrag+0x0078: ld [%g5 + 16], %o5
Current function is std::locale::global
56 setlocale (_RWSTD_LC_ALL, rhs.name ().c_str ());
(dbx) where
current thread: [EMAIL PROTECTED]
[1] defrag(0x5920, 0x59200160,
0x7f72cb18, 0x59200010, 0x592000e0,
0x4f383835392d3520), at 0x7f60dbb8
[2] get_lcinterface(0x7f72c1b8, 0x7f72c370,
0x7e3fb708, 0x0, 0x2000, 0x7f627728), at
0x7f60e1b8
[3] informrtld(0x21e0, 0x2000, 0x7e95e988,
0x7eae6000, 0x158954, 0x101010101010101), at
0x7e98d6fc
[4] _setlocale(0x7c9052f0, 0x7e9dbc7e, 0x6,
0x7c905230, 0x2000, 0x7eaf00b0), at 0x7e98d458
=>[5] std::locale::global(rhs = STRUCT), line 56 in
"locale_global.cpp"
[6] test_global(_ARG1 = 0x7fffe9b8), line 95 in
"22.locale.statics.mt.cpp"
(dbx)
{noformat}
[Solaris Threads] SIGSEGV in 22.locale.statics.mt.cpp
-
Key: STDCXX-811
URL:
https://issues.apache.org/jira/browse/STDCXX-811
Project: C++ Standard Library
Issue Type: Bug
Components: 22. Localization
Affects Versions: 4.2.0
Reporter: Martin Sebor
Assignee: Eric Lemings
Priority: Critical
Fix For: 4.2.1
Original Estimate: 4h
Time Spent: 1h
Remaining Estimate: 3h
Regardless of the compiler (gcc or Sun C++), when compiled
with Solaris Threads instead of POSIX threads, the
[22.locale.statics.mt|http://svn.apache.org/repos/asf/stdcxx/t
runk/tests/localization/22.locale.statics.mt.cpp] fails at
runtime with SIGSEGV or SIGHUP, suggesting a problem with the
uses of Solaris threads mutexes in the library.
I'm assuming this is not a regression but we need to check
the results of the test in 4.2.0 to make sure. If it is one,
it would make the priority of this issue a Blocker.
Otherwise, if it's not a new problem, we might be able to
defer it post 4.2.1 if it's too hard to fix.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
