[jira] Updated: (STDCXX-93) [MSVC 8.0] time_get crashes when calling get_date
[
https://issues.apache.org/jira/browse/STDCXX-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Sebor updated STDCXX-93:
---
Summary: [MSVC 8.0] time_get crashes when calling get_date (was: time_get
crashes when calling get_date ( Visual C++ 8.0 ))
Tweaked Summary to conform to convention.
[MSVC 8.0] time_get crashes when calling get_date
-
Key: STDCXX-93
URL: https://issues.apache.org/jira/browse/STDCXX-93
Project: C++ Standard Library
Issue Type: Bug
Components: Examples
Environment: Visual C++ 8.0
Reporter: Vikas Mehta
Assignee: Martin Sebor
Fix For: 4.2
Test case:
// Following code snippet is taken from examples\manual\time_get.cpp
// NOTE: A SunPro bug requires time.h preceed locale. PR #26255
#include ctime // for struct tm
#include locale // for locale, time_get
#include sstream// for stringstream
#include iostream // for cout, endl
// Print out a tm struct value in one atomic operation
std::ostream operator (std::ostream os, const std::tm t)
{
std::stringstream strm;
strm Daylight Savings = t.tm_isdst
\nDay of year = t.tm_yday
\nDay of week = t.tm_wday
\nYear = t.tm_year
\nMonth= t.tm_mon
\nDay of month = t.tm_mday
\nHour = t.tm_hour
\nMinute = t.tm_min
\nSecond = t.tm_sec
'\n';
// guard for thread safety and output synchronization
const std::ostream::sentry guard (os);
if (guard)
os.rdbuf ()-sputn (strm.str ().c_str (), strm.str ().size ());
else
os.setstate (os.failbit);
return os;
}
int main ()
{
typedef std::istreambuf_iteratorchar, std::char_traitschar Iter;
// time struct to parse date into
static std::tm timeb; // zero initialized
// Unused, required by time_get
std::ios_base::iostate state;
// Stream object to read from
std::istringstream ins ();
// Iterators into the stream object
Iter begin (ins);
Iter end;
// Get a reference to the time_get facet in locale loc.
const std::time_getchar, Iter tg =
std::use_facetstd::time_getchar, Iter (std::locale (C));
// Display time_base::dateorder value.
std::cout time_base::dateorder == tg.date_order () .\n;
// Insert date string into stream.
ins.str (04/07/69);
// get_date from the stream and output tm contents.
tg.get_date (begin, end, ins, state, timeb);
std::cout Date: Apr 7 1969\n timeb std::endl;
return 0;
}
Stack Trace:
msvcr80d.dll!_mbstowcs_l_helper(wchar_t * pwcs=0x008e2b78, const char *
s=0x008e6008, unsigned int n=1812, localeinfo_struct * plocinfo=0x0012f740)
Line 71C++
msvcr80d.dll!_mbstowcs_s_l(unsigned int * pConvertedChars=0x0012f7b0,
wchar_t * pwcs=0x008e2b78, unsigned int sizeInWords=1812, const char *
s=0x008e6008, unsigned int n=4294967295, localeinfo_struct *
plocinfo=0x0012f7d4) Line 259 + 0x30 bytes C++
msvcr80d.dll!_wcsftime_l_stat(wchar_t * wstring=0x008e2b78, unsigned
int maxsize=1812, const wchar_t * wformat=0x00473980, const tm *
timeptr=0x0012f858, localeinfo_struct * plocinfo=0x0012f7d4) Line 101 + 0x32
bytes C++
msvcr80d.dll!_wcsftime_l(wchar_t * wstring=0x008e2b78, unsigned int
maxsize=1812, const wchar_t * wformat=0x00473980, const tm *
timeptr=0x0012f858, localeinfo_struct * plocinfo=0x) Line 152 + 0x1e
bytesC++
msvcr80d.dll!wcsftime(wchar_t * wstring=0x008e2b78, unsigned int
maxsize=1812, const wchar_t * wformat=0x00473980, const tm *
timeptr=0x0012f858) Line 162 + 0x17 bytesC++
time_get.exe!__rw::__rw_get_timepunct(const __rw::__rw_facet *
pfacet=0x0049465c, int flags=64, unsigned int inx=0) Line 695 + 0x28 bytes
C++
time_get.exe!__rw::__rw_get_timepunct(const __rw::__rw_facet *
pfacet=0x0049465c, int flags=64, const void * * names=0x0012fc40, unsigned
int * sizes=0x0012faa8) Line 1115 + 0x11 bytes C++
time_get.exe!__rw::__rw_get_timepunct(const __rw::__rw_facet *
pfacet=0x0049465c, int * data=0x0012fa4c, tm * tmb=0x0012fa78, int * *
pmem=0x0012fa6c, const void * * names=0x0012fc40, unsigned int *
sizes=0x0012faa8) Line 1452 + 0x23 bytesC++
time_get.exe!std::time_getchar,std::istreambuf_iteratorchar,std::char_traitschar
::do_get(std::istreambuf_iteratorchar,std::char_traitschar
__it={...}, std::istreambuf_iteratorchar,std::char_traitschar
__end={...}, std::ios_base __fl={...}, __rw::__rw_iostate
__err=-858993460, tm * __tmb=0x00492518, char __fmt='x', char __modifier=0)
Line 175 + 0x2c bytes C++
RE: STDCXX tests fails and reasons [MSVC]
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Friday, June 29, 2007 8:17 AM To: stdcxx-dev@incubator.apache.org Subject: Re: STDCXX tests fails and reasons [MSVC] Another problem in that test is difference between char_traitschar::eof() == int(-1) and char_traitswchar_t::eof() == int (65536). char_traitswchar_t::eof() should equal WEOF. Is WEOF equal to 65536 on Windows? Yes. Below is a definition of the WEOF in wctype.h (MSVC 8): #define WEOF (wint_t)(0x) The test probably assumes that EOF is the same as WEOF which may not be a safe assumption. Exactly right. The basic_stringbuf::pbackfail() test (line 637) expected EOF == -1 and issues rw_error() diagnostic on whar_t tests. Is this still 27.stringbuf.virtuals.cpp? I don't see any rw_error() in there. Line 637 is the first line with failed test (EOF expected, WEOF got). //+- initial sequence (if any) //| +-- open mode //| | + gbump (gptr offset) //| | | + pbackfail argument //| | | | + expected return value //| | | | |+--- number of putback positions //| | | | || + number of read positions //| | | | || | +- number of write positions //| | | | || | | //V V V V VV V V TEST (0, 0,0, 'c', EOF, 0, 0, -1); Farid.
Re: STDCXX tests fails and reasons [MSVC]
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Friday, June 29, 2007 8:17 AM To: stdcxx-dev@incubator.apache.org Subject: Re: STDCXX tests fails and reasons [MSVC] Another problem in that test is difference between char_traitschar::eof() == int(-1) and char_traitswchar_t::eof() == int (65536). char_traitswchar_t::eof() should equal WEOF. Is WEOF equal to 65536 on Windows? Yes. Below is a definition of the WEOF in wctype.h (MSVC 8): #define WEOF (wint_t)(0x) The test probably assumes that EOF is the same as WEOF which may not be a safe assumption. Exactly right. So let's fix it :) I didn't look very carefully (it's been over a year since I wrote it) but I wonder if we could fix it by translating the EOF used in test cases to char_traitscharT::eof() in the test function. Martin The basic_stringbuf::pbackfail() test (line 637) expected EOF == -1 and issues rw_error() diagnostic on whar_t tests. Is this still 27.stringbuf.virtuals.cpp? I don't see any rw_error() in there. Line 637 is the first line with failed test (EOF expected, WEOF got). //+- initial sequence (if any) //| +-- open mode //| | + gbump (gptr offset) //| | | + pbackfail argument //| | | | + expected return value //| | | | |+--- number of putback positions //| | | | || + number of read positions //| | | | || | +- number of write positions //| | | | || | | //V V V V VV V V TEST (0, 0,0, 'c', EOF, 0, 0, -1); Farid.
RE: 21.string.rfind.cpp test fail reason
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Friday, June 29, 2007 8:24 AM To: stdcxx-dev@incubator.apache.org Subject: Re: 21.string.rfind.cpp test fail reason Farid Zaripov wrote: The problem in 21.string.rfind.cpp test is invoking string::rfind(const value_type* ptr, size_type off = npos, size_type count) with count == string::max_size() + 1 (21.string.rfind.cpp lines 413-416). The method throws length_error() exception (line 756 file string.cc) but test not expected any exceptions. The test should definitely be prepared to deal with exceptions, even if they are not required or allowed. 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. Farid.
RE: STDCXX tests fails and reasons [MSVC]
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Friday, June 29, 2007 8:34 AM To: stdcxx-dev@incubator.apache.org Subject: Re: STDCXX tests fails and reasons [MSVC] Farid Zaripov wrote: The list of the fails and reasons (which I've checked at the moment) is here: http://people.apache.org/~faridz/test_status.html I vaguely recall discussing the problem but I don't see an issue in Jira for the bug in rw_match(char, char, 1). Is this it? http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/ms g01569.html No. the last message is here: http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg01893.htm l Farid.
Re: STDCXX tests fails and reasons [MSVC]
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Friday, June 29, 2007 8:34 AM To: stdcxx-dev@incubator.apache.org Subject: Re: STDCXX tests fails and reasons [MSVC] Farid Zaripov wrote: The list of the fails and reasons (which I've checked at the moment) is here: http://people.apache.org/~faridz/test_status.html I vaguely recall discussing the problem but I don't see an issue in Jira for the bug in rw_match(char, char, 1). Is this it? http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/ms g01569.html No. the last message is here: http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg01893.htm l I see. 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? Martin
RE: status of thread safety tests
Could you add a brief note on how the tests were built and executed? Specifically, were they built and executed with gcc using binary instrumentation or with icc using dynamic instrumentation? Thanks. -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Monday, June 18, 2007 9:20 PM To: stdcxx-dev@incubator.apache.org Subject: status of thread safety tests I've been working on a document listing the thread safety tests in stdcxx/trunk and their current status: http://people.apache.org/~sebor/thread_safety_tests.html The goal is to have a full understanding of all the problems and address them (or at least the most important ones) in the final 4.2.0 release. The document is still a work in progress, as is the test suite. Not all tests have been migrated from the Rogue Wave test suite in Perforce over to ASF Subversion. For those tests the links that point to the Perforce source repository won't work.
[jira] Reopened: (STDCXX-462) std::time_get example exposes undefined behavior
[ https://issues.apache.org/jira/browse/STDCXX-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor reopened STDCXX-462: - Reopened. From http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03786.html: FYI, this is a documentation bug. We need to change the code on the Class Reference page as well: http://incubator.apache.org/stdcxx/doc/stdlibref/time-get.html std::time_get example exposes undefined behavior Key: STDCXX-462 URL: https://issues.apache.org/jira/browse/STDCXX-462 Project: C++ Standard Library Issue Type: Bug Components: Documentation Affects Versions: 4.1.3, 4.1.2 Reporter: Martin Sebor Assignee: Farid Zaripov Priority: Critical Fix For: 4.2 The example program demonstrating the use of the std::time_get facet (http://incubator.apache.org/stdcxx/doc/stdlibref/time-get.html) exposes undefined behavior. Quoting from the following post http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03760.html: Martin Sebor wrote: Farid Zaripov wrote: [...] Btw below is a part of the conforming program (taken from time_get.cpp)? It's not a conforming program. The locale must stay around as long as the last reference to the facet obtained from it. The tests that fail to follow this rule should be changed. --- const std::time_getchar, Iter tg = std::use_facetstd::time_getchar, Iter (std::locale (C)); // Display time_base::dateorder value. std::cout time_base::dateorder == tg.date_order () .\n; --- This fragment fails on Dinkumware STL because of tg.date_order() uses (internal) pointer to the destroyed locale object. Right, and that's allowed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: Intel C++ build issues on Windows
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Friday, June 29, 2007 9:53 PM To: stdcxx-dev@incubator.apache.org Subject: Re: Intel C++ build issues on Windows Andrew Black wrote: Greetings Martin It appears that the build that started on 6/27 entered a hang state due to an undismissed dialog. The utility used to automatically close dialogs was failing for some reason, and the team responsible for the automated build system has been working on resolving it. I see. I thought we cleaned them all up. Farid, are there any more tests or examples that you're aware of that could be causing this? I suppose it's always possible that a test will crash and pop up a window on the screen (what a pain!) We really need to come up with a reliable way to prevent this. There are 3 types of popup's: 1) Dr.Watson window, appear on access violation or unhandled exception; 2) CRT asserts and parameter validat The other two builds that started last night have completed, though are reporting back in a ERROR state. So they are. The config header or log aren't available, even though it looks like they were successfully created. There might be useful information in there. Are they not getting saved in the database? And if not, is there a way to save them? Since Farid says he can't reproduce it in his environment there must be a difference between ours and his. Farid, what is the exact version of Intel C++ and MSVC that you're using on Windows? Our logs indicate we are at 9.1.028 for icl and Visual Studio 2005. Andrew, do you know if we're have a service pack installed for Visual Studio and if so, what version it is? Ditto for the OS. Intel Compiler: - Intel(R) C++ Compiler for 32-bit applications, Version 9.1Build 20060323Z Copyright (C) 1985-2006 Intel Corporation. All rights reserved. - Intel Compiler Integration: - Intel(R) C++ Compiler Integration for Microsoft Visual Studio 2005, Version 9.1.590.2005 , Copyright (C) 2002-2006 Intel Corporation. - Farid, is there a way to determine the exact versions (including patches or service packs) of theses things on Windows? If there is, would it be possible to enhance the Windows infrastructure to write all this information out somewhere? E.g., as the first step of the configuration process where we currently say (something like): Configuring for icc-9.1 - 12d Optimized Thread-safe Dll It would be useful to enhance this to give more detail, e.g., Configuring for icc-9.1.028 (Visual Studion 2005, Service Pack X) - 12d Optimized Thread-safe Dll on Windows 2000, Service Pack Y. Good idea. I will try to deal with it. Farid.
Re: status of thread safety tests
Eric Lemings wrote: Could you add a brief note on how the tests were built and executed? Specifically, were they built and executed with gcc using binary instrumentation or with icc using dynamic instrumentation? Good suggestion! I used icc with the -tcheck option to compile and link the tests and ran the executables through the tcheck_cl driver (silly name, btw.) I would expect the results to be the same when I use gcc. I've tried using it but didn't actually compare the results. It might be an interesting project. Let me put the info on the page the next time I update it. Martin Thanks. -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Monday, June 18, 2007 9:20 PM To: stdcxx-dev@incubator.apache.org Subject: status of thread safety tests I've been working on a document listing the thread safety tests in stdcxx/trunk and their current status: http://people.apache.org/~sebor/thread_safety_tests.html The goal is to have a full understanding of all the problems and address them (or at least the most important ones) in the final 4.2.0 release. The document is still a work in progress, as is the test suite. Not all tests have been migrated from the Rogue Wave test suite in Perforce over to ASF Subversion. For those tests the links that point to the Perforce source repository won't work.
[jira] Commented: (STDCXX-463) [HP-UX 11.23] printf(%Lg, -NAN) formatted incorrectly
[
https://issues.apache.org/jira/browse/STDCXX-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509642
]
Martin Sebor commented on STDCXX-463:
-
Response from HP:
Original Message
Subject: Re: HP-UX 11.23 printf(%Lg, -NAN) formatted incorrectly
Date: Thu, 28 Jun 2007 20:14:30 -0700 (PDT)
From: Dennis Handly [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
From: Martin Sebor [EMAIL PROTECTED]
On 11.23/PA, printf(%g) formats negative NaN correctly (by
prepending the minus) but with %Lg it forgets the sign.
On 11.31/IPF printf() works correctly.
-std::numeric_limitslong double::quiet_NaN()
This works correctly on all IPF versions. Because the IPF libc has
_U_Qfneg and PA doesn't. The PA compiler uses _U_Qfsub which doesn't
produce negative NaNs.
Are there plans to backport the fix to prior versions of HP-UX and/or PA?
Martin
I seriously doubt it. libc would have to change and then all of the
compilers.
There were other CRs about negating NaNs:
JAGaa73927 NaN signs not respected
JAGaa86217 Incorrect printing of long double NaNs
JAGaa91576 Signed NaNs aren't generated correctly (see JAGaa78419 for C equiv)
JAGaa78419 NaN signs not respected (2)
JAGad01217 incorrect display of -nan from printf in libc
[HP-UX 11.23] printf(%Lg, -NAN) formatted incorrectly
---
Key: STDCXX-463
URL: https://issues.apache.org/jira/browse/STDCXX-463
Project: C++ Standard Library
Issue Type: Bug
Components: External
Environment: HP-UX 11.23 and prior
Reporter: Martin Sebor
Original Message
Subject: HP-UX 11.23 printf(%Lg, -NAN) formatted incorrectly
Date: Thu, 28 Jun 2007 19:34:32 -0600
From: Martin Sebor [EMAIL PROTECTED]
Organization: Rogue Wave Software
To: [EMAIL PROTECTED]
Hi,
On 11.23/PA, printf(%g) formats negative NaN correctly (by
prepending the minus) but with %Lg it forgets the sign. On
11.31/IPF printf() works correctly. Are there plans to backport
the fix to prior versions of HP-UX and/or PA?
Thanks
Martin
$ cat t.cpp aCC -AA t.cpp ./a.out
#include assert.h
#include stdio.h
#include string.h
#include limits
int main ()
{
char nan [32];
char nnan [32];
char lnan [32];
char nlnan [32];
sprintf (nan, %g, std::numeric_limitsdouble::quiet_NaN ());
sprintf (nnan, %g, -std::numeric_limitsdouble::quiet_NaN ());
sprintf (lnan, %Lg, std::numeric_limitslong double::quiet_NaN ());
sprintf (nlnan, %Lg, -std::numeric_limitslong double::quiet_NaN ());
printf (%s, %s\n%s, %s\n, nan, nnan, lnan, nlnan);
assert (0 == strcmp (nan, lnan));
assert (0 == strcmp (nnan, nlnan));
}
nan, -nan
nan, nan
Assertion failed: 0 == strcmp (nnan, nlnan), file t.cpp, line 21
ABORT instruction (core dumped)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: MSVC8 CRT Secure Template Overloads feature and stdcxx
Martin Sebor wrote:
Farid Zaripov wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Wednesday, June
13, 2007 6:24 PM
To: stdcxx-dev@incubator.apache.org
Subject: Re: MSVC8 CRT Secure Template Overloads feature and stdcxx
Since va_list can be anything, we need to pass va_list type in
function call.
We can add function template class T get_t () { T t;
return t; } to
the libc_decl.sh and use the followinf declaration:
vsprintf((char*)0,0,get_tva_list())
in headers.inc.
Wouldn't vsprintf((char*)0,0,va_list()) work?
I think this should work.
My concern here is with the va_list name: Is it required to be
declared in the same header as the functions that use it?
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.
Martin
Re: Intel C++ build issues on Windows
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Friday, June 29, 2007 9:53 PM To: stdcxx-dev@incubator.apache.org Subject: Re: Intel C++ build issues on Windows [...] Farid, what is the exact version of Intel C++ and MSVC that you're using on Windows? Our logs indicate we are at 9.1.028 for icl and Visual Studio 2005. Andrew, do you know if we're have a service pack installed for Visual Studio and if so, what version it is? Ditto for the OS. Intel Compiler: - Intel(R) C++ Compiler for 32-bit applications, Version 9.1Build 20060323Z The latest 9.1 patch is 9.1.038 dated 2007/05/10. We appear to be at 9.1.028, which is quite a bit out of date (dated 2006/07/06). Yours is even older and corresponds to 9.1.022. I think we all need to upgrade to the latest patch and see if the issue persists. Martin
Re: 21.string.rfind.cpp test fail reason
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Friday, June 29, 2007 8:24 AM To: stdcxx-dev@incubator.apache.org Subject: Re: 21.string.rfind.cpp test fail reason Farid Zaripov wrote: The problem in 21.string.rfind.cpp test is invoking string::rfind(const value_type* ptr, size_type off = npos, size_type count) with count == string::max_size() + 1 (21.string.rfind.cpp lines 413-416). The method throws length_error() exception (line 756 file string.cc) but test not expected any exceptions. The test should definitely be prepared to deal with exceptions, even if they are not required or allowed. 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(). 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. Btw., library issue 625 highlights some of the problems in string due to the inconsistent use of Effects and Returns clauses: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#625 Martin
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? Martin Modified: incubator/stdcxx/trunk/include/rw/_iosbase.h Modified: incubator/stdcxx/trunk/include/rw/_iosbase.h URL: http://svn.apache.org/viewvc/incubator/stdcxx/trunk/include/rw/_iosbase.h?view=diffrev=550837r1=550836r2=550837 == --- incubator/stdcxx/trunk/include/rw/_iosbase.h (original) +++ incubator/stdcxx/trunk/include/rw/_iosbase.h Tue Jun 26 09:01:18 2007 @@ -291,13 +291,13 @@ typedef void (*event_callback)(event, ios_base, int); -// 27.5.2.6, p1 +// 27.4.2.6, p1 void register_callback (event_callback, int); // 27.4.2.4, p1 static bool sync_with_stdio (bool = true); -// 27.5.2.7, p2 +// 27.4.2.7, p2 virtual ~ios_base (); // returns a numeric base as per 22.2.2.1.2, p4 @@ -307,7 +307,7 @@ protected: -// 27.5.2.7, p1 +// 27.4.2.7, p1 ios_base (); // implements basic_iosT::init()
Re: svn commit: r546535 - /incubator/stdcxx/trunk/include/sstream
[EMAIL PROTECTED] wrote:
Author: faridz
Date: Tue Jun 12 08:39:20 2007
New Revision: 546535
URL: http://svn.apache.org/viewvc?view=revrev=546535
Log:
2007-06-12 Farid Zaripov [EMAIL PROTECTED]
* sstream (str): Method definition moved outside of the class
definition.
Modified:
incubator/stdcxx/trunk/include/sstream
Modified: incubator/stdcxx/trunk/include/sstream
URL:
http://svn.apache.org/viewvc/incubator/stdcxx/trunk/include/sstream?view=diffrev=546535r1=546534r2=546535
==
--- incubator/stdcxx/trunk/include/sstream (original)
+++ incubator/stdcxx/trunk/include/sstream Tue Jun 12 08:39:20 2007
[...]
@@ -194,6 +177,28 @@
void _C_catchup (char_type*);
};
+template class _CharT, class _Traits, class _Allocator
+inline basic_string_CharT, _Traits, _Allocator
+basic_stringbuf_CharT, _Traits, _Allocator::
+str () const {
In member functions defined outside the definition of their
class the opening brace goes on a line all by itself. It's
also nice to separate namespace-scope definitions by two
blank lines rather than just one (it makes it easier to
tell individual function definitions apart).
+
+const char_type * __first = 0;
+const char_type * __last = 0;
There should be a space only on one side of the asterisk,
not both. I.e., like this:
const char_type* __first = 0;
const char_type* __last = 0;
I made the changes here:
http://svn.apache.org/viewvc?view=revrev=552661
Martin
Re: STDCXX examples fails and reasons [MSVC]
Farid Zaripov wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 21, 2007 8:56 PM
To: stdcxx-dev@incubator.apache.org
Subject: Re: STDCXX examples fails and reasons [MSVC]
[...]
time_put like a bug in our infrastructure (I assume the
example assumes a certain time zone and it's being run in
another). The latter could (should?) be fixed by setting
the TZ environment variable time zone to the expected zone
before invoking this example.
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? :) 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.
Martin
Index: makefile.rules
===
--- makefile.rules (revision 549750)
+++ makefile.rules (working copy)
@@ -119,8 +119,9 @@
PATH=$$PATH:.;
\
TOPDIR=$(TOPDIR);
\
TMP=$${TMP:-/tmp}/stdcxx-run-;
\
+TZ=MST+7;
\
export TMP;
\
-export LD_LIBRARY_PATH PATH TMP TOPDIR;
\
+export LD_LIBRARY_PATH PATH TMP TOPDIR TZ;
\
trap rm -rf $$TMP HUP INT QUIT TERM EXIT;
\
mkdir -p $$TMP;
\
./run $(RUNFLAGS) $(RUNTARGET);
\
@@ -133,8 +134,9 @@
PATH=$$PATH:$(LIBDIR):.;
\
TOPDIR=$(TOPDIR);
\
TMP=$${TMP:-/tmp}/stdcxx-run-;
\
+TZ=MST+7;
\
export TMP;
\
-export LD_LIBRARY_PATH PATH TMP TOPDIR;
\
+export LD_LIBRARY_PATH PATH TMP TOPDIR TZ;
\
trap rm -rf $$TMP HUP INT QUIT TERM EXIT;
\
mkdir -p $$TMP;
\
./run $(RUNFLAGS) $(RUNTARGET);
\
Farid.
