[jira] Created: (STDCXX-466) basic_string::rfind() throws length_error(), but should return npos
basic_string::rfind() throws length_error(), but should return npos - Key: STDCXX-466 URL: https://issues.apache.org/jira/browse/STDCXX-466 Project: C++ Standard Library Issue Type: Bug Components: 21. Strings Affects Versions: 4.2 Environment: All Reporter: Farid Zaripov The details are here: http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03795.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: 21.string.rfind.cpp test fail reason
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Tuesday, July 03, 2007 7:02 AM To: stdcxx-dev@incubator.apache.org Subject: Re: 21.string.rfind.cpp test fail reason The test deals with exceptions (the all exceptions are catched). I mean that concrete test line not expected any exception and issues rw_error() when length_error() catched. I don't see any calls to rw_error() in 21.string.rfind.cpp but you probably meant rw_assert(). Yes, I mean rw_assert(). Sorry. rfind() is not required to and shouldn't throw under any conditions. There's no efficient way for all the overloads of rfind() to throw consistently under the same conditions so it should just return npos instead. We need a Jira issue to track this change. http://issues.apache.org/jira/browse/STDCXX-466 Farid.
RE: STDCXX examples fails and reasons [MSVC]
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Tuesday, July 03, 2007 7:38 AM To: stdcxx-dev@incubator.apache.org Subject: Re: STDCXX examples fails and reasons [MSVC] I have updated the windows build infrastructure to set TZ environment variable before run examples. The proposed similar changes in unix infrastructure below, but I'm not sure that is correct: Why not? :) Because in windows infrastructure the TZ environment variable is set for all examples only, but my patch in unix infrastructure sets TZ variable for tests also. If you're not sure it's portable check out the TZ section in POSIX: http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html Any of MST7, MST07, MST+7, and MST+07 should work. If it works on the platforms you have access to (Linux and HP-UX) I say check it in and keep an eye out on failures for a few days to make sure it works everywhere else. Farid.
RE: svn commit: r550837 - /incubator/stdcxx/trunk/include/rw/_iosbase.h
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Tuesday, July 03, 2007 7:17 AM To: stdcxx-dev@incubator.apache.org Subject: Re: svn commit: r550837 - /incubator/stdcxx/trunk/include/rw/_iosbase.h [EMAIL PROTECTED] wrote: Author: faridz Date: Tue Jun 26 09:01:18 2007 New Revision: 550837 URL: http://svn.apache.org/viewvc?view=revrev=550837 Log: 2007-06-26 Farid Zaripov [EMAIL PROTECTED] * _iosbase.h: Fixed references to standard. Thanks for correcting these. FWIW, I think the best way to deal with these references going forward will be to remove them all since some or possibly even many of the clause numbers are likely to change in the next standard. Plus, I don't even find them very helpful -- do you? I used this reference when I investigated the access violation problem in 22.locale.num.put.mt.cpp test: http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03781.htm l Farid.
RE: STDCXX tests fails and reasons [MSVC]
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Monday, July 02, 2007 8:23 PM To: stdcxx-dev@incubator.apache.org Subject: Re: STDCXX tests fails and reasons [MSVC] Jira for the bug in rw_match(char, char, 1). But is that really a bug in rw_match()? It looks to me more like a design limitation than a bug. In the case of the wchar_t* and UserChar* overloads of rw_match() there should be a simple solution: make sure the first (char*) argument has enough elements (it should be easy to guarantee that since the argument is the hardcoded string we match against). And changing the char* overload to behave the same as the other two, i.e., to only do the expansion on the first argument and not on the second should fix that case, no? The problem is in that rw_match() used to compare single characters. There no problem in compare one character NUL-terminated string (i.e. b or [EMAIL PROTECTED]). We should not use rw_match() to compare single characters. Farid.
RE: Intel C++ build issues on Windows
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Tuesday, July 03, 2007 7:08 AM To: stdcxx-dev@incubator.apache.org Subject: Re: Intel C++ build issues on Windows There are 3 types of popup's: 1) Dr.Watson window, appear on access violation or unhandled exception; 2) CRT asserts ; 3) Parameter validattion handler popup's. The 1) prevented in exec utility (SetErrorMode()). The 2) and 3) might be prevented by installing report hook and invalid parameter handler: http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03761.h tm l Gotcha! I see I still owe you a response to your feedback in that thread. The solution in 2) and 3) will only take care of these popups in tests and not in examples or config tests (or locales?) Yes. We'll also need a solution for those executables (but we can worry about that once we're done enhancing the test driver). We can install the similar handlers in each example, but I don't see any 2) of 3) popups in examples at the moment. Farid.
RE: MSVC8 CRT Secure Template Overloads feature and stdcxx
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Monday, July 02, 2007 10:50 PM To: stdcxx-dev@incubator.apache.org Subject: Re: MSVC8 CRT Secure Template Overloads feature and stdcxx On gcc 3.4.4/Cygwin the va_list type is not defined in stdio.h. Right. The C standard requires that stdarg.h be #included before calling vsnprintf(). To do what you want you'd need to find a way (ideally a general mechanism) to also #include stdarg.h in these tests. So what's the status of this improvement? I didn't mean to shoot it down completely, just point out the problem with it on other platforms. Since this is an MSVC-specific feature it wouldn't be completely inappropriate to devise an MSVC-specific solution for it. We can extend headers.inc with additional data on headers and types, i.e.: # list of headers hdrs=assert ctype errno float iso646 limits locale math setjmp signal \ stdarg stddef stdio stdlib string time wchar wctype new typeinfo hdrs=$hdrs ieeefp.h pthread.h # list of types in header stdarg_h=va_list stddef_h=size_t ptrdiff_t And then search and #include header which define the type, used in function call. Farid.
[jira] Created: (STDCXX-467) [Intel Thread Checker 3.1] bogus data race after pthread_once()
[Intel Thread Checker 3.1] bogus data race after pthread_once()
---
Key: STDCXX-467
URL: https://issues.apache.org/jira/browse/STDCXX-467
Project: C++ Standard Library
Issue Type: Bug
Components: External
Environment: Intel Thread Checker 3.1 with Intel C++ 9.1.049 on Red
Hat Enterprise Linux AS release 4 (Nahant Update 4)
Reporter: Martin Sebor
Running the program below through the thread checker gives the Wrtite-Read
data race error shown in the output:
$ cat t.c icc -V t.c -pthread tcheck_cl -v a.out
#include pthread.h
static int flag;
static void init () { flag = 1; }
static pthread_once_t flag_init;
static int foo () {
pthread_once (flag_init, init);
return flag;
}
static void* thr_func (void *a) {
int i;
int n = 0;
for (i = 0; i != 100; ++i)
n += foo ();
return (void*)n;
}
int main () {
pthread_t pid [2];
int i;
for (i = 0; i != sizeof pid / sizeof *pid; ++i)
pthread_create (pid + i, 0, thr_func, 0);
for (i = 0; i != sizeof pid / sizeof *pid; ++i)
pthread_join (pid [i], 0);
}
Intel(R) C Compiler for Intel(R) EM64T-based applications, Version 9.1Build
20070320 Package ID: l_cc_c_9.1.049
Copyright (C) 1985-2007 Intel Corporation. All rights reserved.
Edison Design Group C/C++ Front End, version 3.6 (Mar 22 2007 02:18:08)
Copyright 1988-2005 Edison Design Group, Inc.
GNU ld version 2.15.92.0.2 20040927
Intel(R) Thread Checker 3.1 command line instrumentation driver (24400)
Copyright (c) 2007 Intel Corporation. All rights reserved.
Building project
Instrumenting
14% a.out ( All Functions ):..
Running: /build/sebor/stdcxx-icc-9.1_049-15S/tests/a.out
Application finished
___
|ID|Short Des|Sever|Co|Contex|Description |1st Ac|2nd Acc|
| |cription |ity |un|t[Best| |cess[B|ess[Bes|
| | |Name |t |] | |est] |t] |
___
|1 |Write - |Error|10|[a.out|Memory read at [a.out, 0x7b9]|[a.out|[a.out,|
| |Read | |0 |, |conflicts with a prior memory|, |0x7b9] |
| |data-race| | |0x79a]|write at [a.out, 0x7d0] (flow|0x7d0]| |
| | | | | |dependence) | | |
___
|2 |Thread te|Infor|1 |WholeP|Thread termination at [a.out,|[a.out|[a.out,|
| |rmination|matio| |rogram|0x762] - includes stack |, |0x762] |
| | |n| |1 |allocation of 10.004 MB and use |0x762]| |
| | | | | |of 5.047 KB | | |
___
|3 |Thread te|Infor|1 |WholeP|Thread termination at [a.out,|[a.out|[a.out,|
| |rmination|matio| |rogram|0x762] - includes stack |, |0x762] |
| | |n| |2 |allocation of 10.004 MB and use |0x762]| |
| | | | | |of 4.984 KB | | |
___
|4 |Thread te|Infor|1 |WholeP|Thread termination at [a.out,|[a.out|[a.out,|
| |rmination|matio| |rogram|0x728] - includes stack |, |0x728] |
| | |n| |3 |allocation of 10 MB and use of |0x728]| |
| | | | | |1.984 KB | | |
___
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
