Re: STDCXX progress to graduation
Leo Simons wrote: On Jun 23, 2007, at 10:06 PM, Martin Sebor wrote: Leo Simons wrote: I also believe/hope the status file might need an update or perhaps two: In progress Check and make sure that the files that have been donated have been updated to reflect the new ASF copyright. I'd hope that was finished a while ago :-) It got started but we never did go through all the files to check that we didn't miss any (which we of course did). :-( I just finished a sweep through our sources and updated those that still needed it. The record of the changes is here: https://issues.apache.org/jira/browse/STDCXX-457 So, does this mean that there's files in any of the tarballs listed at http://incubator.apache.org/stdcxx/download.html that have an incorrect license header? Incorrect might be too strong a word. IMO, different would describe it better. If so, you should be thinking about what to do with those releases -- like do a branch where you fix the headers and release new 4.1.2.2, 4.1.3.2 versions to replace them, or simply pull the 4.1.x releases and get 4.2 out quickly, or decide there really can't possibly be any problems for the users but add a warning to be safe, or successfully argue there's nothing that needs to be done, or whatever. I'd like to argue that nothing needs to be done :) The files are all licensed under the ASL, it's just that the text is subtly (but in my layman opinion not substantively) different from the most recent text at http://www.apache.org/legal/src-headers.html I think you're blessed with mentors that can offer some very expertish insights into how to deal with things like this :-) We couldn't agree more. Martin
[jira] Created: (STDCXX-458) limits example status depends on platform
limits example status depends on platform - Key: STDCXX-458 URL: https://issues.apache.org/jira/browse/STDCXX-458 Project: C++ Standard Library Issue Type: Bug Components: Examples Affects Versions: 4.1.2 Environment: All Reporter: Farid Zaripov Priority: Minor The limits example expected to output inf for Infinity, nan for Quiet NAN and Signaling NAN. But actually the output depends on the platform (see STDCXX-51). The example should produce the inf for Infinity, the qnan for Quiet NAN and snan for Signaling NAN on all platforms (http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03703.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-459) time_get::date_order() should return actually date order taken from locale
time_get::date_order() should return actually date order taken from locale -- Key: STDCXX-459 URL: https://issues.apache.org/jira/browse/STDCXX-459 Project: C++ Standard Library Issue Type: Improvement Components: 22. Localization Affects Versions: 4.1.2 Environment: All Reporter: Farid Zaripov Priority: Minor The current implementation of the time_get::date_order() always returns no_order. It should return date order used by a locale facet (http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03734.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-460) The time_get example expected to output time_base::dateorder == 2 but actually output is time_base::dateorder == 0.
The time_get example expected to output time_base::dateorder == 2 but actually output is time_base::dateorder == 0. --- Key: STDCXX-460 URL: https://issues.apache.org/jira/browse/STDCXX-460 Project: C++ Standard Library Issue Type: Bug Components: Examples Affects Versions: 4.1.2 Environment: All. Reporter: Farid Zaripov Priority: Minor The time_get example expected to output time_base::dateorder == 2 but actually output is time_base::dateorder == 0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: STDCXX examples fails and reasons [MSVC]
-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] [...] For the rest, we should open issues in Jira so we don't forget to get back to them. I have created the issues STDCXX-458 for limits example and STDCXX-460 for time_get example. codecvt1 should probably be disabled for now (until we figure out how to get it to work) and it should also be renamed to something more descriptive. Testing three hardwired encodings doesn't seem like a good idea for a simple example, so maybe we could split it up into codecvt-sjis.cpp, codecvt-eucjp, and codecvt-utf8.cpp. Let me know your thoughts. I think it sounds reasonable to use no more than one locale in single example. Farid.
RE: STDCXX examples fails and reasons [MSVC]
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Friday, June 22, 2007 6:20 PM To: stdcxx-dev@incubator.apache.org Subject: 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_get looks like a bug (or lack of functionality) in our library time_get::date_order() returns time_get::do_date_order() which always returns dateorder () == no_order (loc/_time_get.h; line 137). Right. We ran out of time when implementing the facet. The standard doesn't require us to do any better so there hasn't been a lot of pressure to get back to it and finish the job, but that doesn't mean we should never do it. From a QoI point of view we definitely should. Ok. I have created the issue STDCXX-459. Also I observed that time_get::~time_get() should be protected (22.2.5.1), but in our library the time_get::~time_get() is not declared/defined. Yes, it is declared as protected in the standard to prevent standalone facet objects from being constructed. I'm not sure that's a detectable requirement. Violations of the requirement are detectable by non-conforming programs, but I can't think of a way how conformance to it could be detected -- can you? It would be difficult. :) The same situation with ~time_get_byname(), ~time_put(), ~time_put_byname(). Our implementation lets users construct facet objects and use (at least some) them directly rather than going through the use_facet interface, which seems like a reasonable thing to do. Can you think of a reason not to keep this extension? No :) Btw below is a part of the conforming program (taken from time_get.cpp)? --- 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. Farid.
Re: STDCXX progress to graduation
William A. Rowe, Jr. wrote: Martin Sebor wrote: It got started but we never did go through all the files to check that we didn't miss any (which we of course did). I just finished a sweep through our sources and updated those that still needed it. The record of the changes is here: https://issues.apache.org/jira/browse/STDCXX-457 Had you happened to run RAT through the sources yet? No. I'm pretty comfortable with the review I just did but if you think it would be useful to run the tool we can look into it. Is there an easy way to run it? All I could find in the way of info on this RAT was this site: http://mojo.codehaus.org/rat-maven-plugin/index.html It looks like it requires Mave. We have no experience with Maven so I'm a little intimidated by what setting it all up might involve. If the goal is to check that every file has the appropriate license header at the top I suspect we can do that more quickly using grep or sed (which is what I did by hand). Martin
Re: STDCXX examples fails and reasons [MSVC]
Farid Zaripov wrote: [...] time_get looks like a bug (or lack of functionality) in our library time_get::date_order() returns time_get::do_date_order() which always returns dateorder () == no_order (loc/_time_get.h; line 137). Right. We ran out of time when implementing the facet. The standard doesn't require us to do any better so there hasn't been a lot of pressure to get back to it and finish the job, but that doesn't mean we should never do it. From a QoI point of view we definitely should. Ok. I have created the issue STDCXX-459. Thanks! Also I observed that time_get::~time_get() should be protected (22.2.5.1), but in our library the time_get::~time_get() is not declared/defined. Yes, it is declared as protected in the standard to prevent standalone facet objects from being constructed. I'm not sure that's a detectable requirement. Violations of the requirement are detectable by non-conforming programs, but I can't think of a way how conformance to it could be detected -- can you? It would be difficult. :) Difficult is not impossible :) If you think it's possible we have a conformance problem. Otherwise, if you don't believe it's possible, we're fine. The same situation with ~time_get_byname(), ~time_put(), ~time_put_byname(). Our implementation lets users construct facet objects and use (at least some) them directly rather than going through the use_facet interface, which seems like a reasonable thing to do. Can you think of a reason not to keep this extension? No :) 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. Martin
Re: Getting incorrect behavior on strstream
Farid Zaripov wrote: -Original Message- From: Jeremy Dean [mailto:[EMAIL PROTECTED] Sent: Friday, June 22, 2007 11:45 PM To: stdcxx-dev@incubator.apache.org Subject: Getting incorrect behavior on strstream I have a testcase that is showing incorrect behavior ostrstream or ostringstream: [...] Any thoughts on this problem? ostrstream::str() returns just the beginning pointer to the sequence. The sequence don't have the null character unless you especially inserted it. You should print no more that otrstream::pcount() characters. See Remarks on the page Better yet, refer to the stdcxx Class Reference :) http://incubator.apache.org/stdcxx/doc/stdlibref/strstreambuf.html#idx1224 Martin
Re: STDCXX progress to graduation
On 6/25/07, Martin Sebor [EMAIL PROTECTED] wrote: Had you happened to run RAT through the sources yet? No. I'm pretty comfortable with the review I just did but if you think it would be useful to run the tool we can look into it. Is there an easy way to run it? All I could find in the way of info on this RAT was this site: http://mojo.codehaus.org/rat-maven-plugin/index.html It looks like it requires Mave. We have no experience with Maven so I'm a little intimidated by what setting it all up might involve. If the goal is to check that every file has the appropriate license header at the top I suspect we can do that more quickly using grep or sed (which is what I did by hand). RAT's homepage is: http://code.google.com/p/arat/ It doesn't require Maven - folks on the general@ list can help handhold its usage. But, sed/grep is just fine too. Though, do expect Robert or some other RAT devs to run releases through there next time we conduct a release - if we're still here in the Incubator. -- justin
Re: svn commit: r550545 - in /incubator/stdcxx/trunk/tests/localization: 22.locale.ctype.is.cpp 22.locale.ctype.narrow.cpp 22.locale.ctype.scan.cpp 22.locale.ctype.tolower.cpp 22.locale.ctype.toupper.
[EMAIL PROTECTED] wrote: Author: faridz Date: Mon Jun 25 09:50:10 2007 New Revision: 550545 Thanks for taking care of this! IIRC, you made a similar change before, suggesting the rw_locales() API is error-prone. I wonder if we should change it so as to return instead of 0 on error. Incidentally, why does it fail in your environment? Martin
Re: Getting incorrect behavior on strstream
I agree with Farid that test2() and test3() exhibit undefined
behavior because they both fail to append the required NUL to
the string before formatting it via the %s printf directive.
But the test program does demonstrate a real problem, and that
is the formatting of infinity when the stream precision is
greater than 7. It looks as though the num_put facet inserts
the string inf\0\0ity into the stream rather than inf.
A small test case is below.
Please go ahead and open an issue for this in Jira.
Martin
$ cat u.cpp make u ./u | od -c
#include cassert
#include iostream
#include sstream
int main () {
std::ostringstream s;
s.precision (8);
s 1 / 0.0;
std::cout s.str () '\n';
assert (s.str () == inf);
}
gcc -c -I/build/sebor/stdcxx/include/ansi -D_RWSTDDEBUG
-D_RWSTD_USE_CONFIG -I/build/sebor/stdcxx/include
-I/build/sebor/stdcxx-gcc-4.1.0-11s/include
-I/build/sebor/stdcxx/examples/include -pedantic -nostdinc++ -g -W
-Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long u.cpp
u.cpp: In function 'int main()':
u.cpp:8: warning: division by zero in '1 / 0.'
gcc u.o -o u -L/build/sebor/stdcxx-gcc-4.1.0-11s/lib -lstd11s -lsupc++
-lm
Assertion failed: s.str () == inf, file u.cpp, line 10
000 i n f \0 \0 i t y \n
011
Jeremy Dean wrote:
I have a testcase that is showing incorrect behavior ostrstream or
ostringstream:
#include cstdio
#include iostream
#include iomanip
#include sstream
#include strstream
#include cmath
void test1() {
std::ostringstream S;
long double x = std::pow(1e300,2);
S Somethingstd::setprecision(8) x;
S else;
std::printf(Test1: %s\n, S.str().c_str());
}
void test2() {
std::ostrstream S;
long double x = std::pow(1e300,2);
S Something std::setprecision(7) x;
S else;
std::printf(Test2: %s\n, S.str());
}
void test3() {
std::ostrstream S;
long double x = 0.0/0.0;
S Something std::setprecision(8) x;
S else;
std::printf(Test3: %s\n, S.str());
}
int main(int argc, char* argv[]) {
test1();
test2();
test3();
}
On solaris 8 with Sun Studio 8 patch 14 I get the following output
Test1: Something inf
Test2: Something inf else else
Test3: Something nan else
Test1 is missing else
Test2 has an extra else
Test3 looks ok.
On RedHat 3u6 I get the following output:
Test1: Something inf else
Test2: Something inf else
Test3: Something nan elseing inf else
Test1 and 2 look ok
Test3 however has extra output ing inf else
Any thoughts on this problem?
Thanks,
Jeremy
Jeremy Dean
Rogue Wave Software,
A QUOVADX(tm) division
Technical Support
Phone: 303-545-3205 -- 1-800-404-4767
E-mail: [EMAIL PROTECTED]
Web: http://www.roguewave.com/support
Knowledge Base entries:
http://www.roguewave.com/kbdocs/search.html
View issues online at:
http://www.roguewave.com/youraccount/login/
RE: Getting incorrect behavior on strstream
Ok, so I added the S std::ends; to each of the stream statements.
This did resolve it on Red hat, however on Solaris for the first
testfunction it did not:
void test1() {
std::ostringstream S;
long double x = std::pow(1e300,2);
S Somethingstd::setprecision(8) x;
S else;
S std::ends;
std::printf(Test1: %s\n, S.str().c_str());
}
On solaris it is printing up until the double and then nothing else is
printed. However if I change the precision to less then 8 then it works
fine.
Jeremy
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Monday, June 25, 2007 11:36 AM
To: stdcxx-dev@incubator.apache.org
Subject: Re: Getting incorrect behavior on strstream
Farid Zaripov wrote:
-Original Message-
From: Jeremy Dean [mailto:[EMAIL PROTECTED]
Sent: Friday, June 22, 2007 11:45 PM
To: stdcxx-dev@incubator.apache.org
Subject: Getting incorrect behavior on strstream
I have a testcase that is showing incorrect behavior ostrstream or
ostringstream:
[...]
Any thoughts on this problem?
ostrstream::str() returns just the beginning pointer to the
sequence.
The sequence don't
have the null character unless you especially inserted it. You should
print no more that
otrstream::pcount() characters.
See Remarks on the page
Better yet, refer to the stdcxx Class Reference :)
http://incubator.apache.org/stdcxx/doc/stdlibref/strstreambuf.html#idx12
24
Martin
Re: STDCXX progress to graduation
On Jun 25, 2007, at 4:53 PM, Martin Sebor wrote: Leo Simons wrote: I just finished a sweep through our sources and updated those that still needed it. The record of the changes is here: https://issues.apache.org/jira/browse/STDCXX-457 So, does this mean that there's files in any of the tarballs listed at http://incubator.apache.org/stdcxx/download.html that have an incorrect license header? Incorrect might be too strong a word. IMO, different would describe it better. If so, you should be thinking about what to do with those releases -- like do a branch where you fix the headers and release new 4.1.2.2, 4.1.3.2 versions to replace them, or simply pull the 4.1.x releases and get 4.2 out quickly, or decide there really can't possibly be any problems for the users but add a warning to be safe, or successfully argue there's nothing that needs to be done, or whatever. I'd like to argue that nothing needs to be done :) The files are all licensed under the ASL, it's just that the text is subtly (but in my layman opinion not substantively) different from the most recent text at http://www.apache.org/legal/src-headers.html Oh, in that case I also think (IANAL, blah, blah) it should be ok. We've had a bunch of different source headers, and on average we haven't pulled releases over them. Thanks for clearing this up :-) - Leo
Re: Convert MSVC CRT debug reports to rwtest driver debug reports
Farid Zaripov wrote: In some tests in debug mode GUI popups appear. We can disable this popups by using _CrtSetReportMode(, _CRTDBG_MODE_DEBUG), but I think it would be useful to convert them into the rwtest debug reports (rw_warn(), rw_error(), rw_assert()). This conversion can be made by installing custom hook function. Sounds reasonable, but I'd like to know a little bit more about what types of errors we're dealing with here. Which of the three types of diagnostics does your patch convert them to? I think rw_error() would be appropriate for undefined behavior like memory corruption detected by the CRT, etc. What other types of errors cause these popups? And also MSVC8 CRT performs parameter checking with invoking Dr.Watson tool (the result is GUI popup) in case the invalid parameter was passed to the CRT function. I suggest to convert this popups to the rw_note() reports (or maybe rw_error()). In terms of the severity, rw_note() is quite different from rw_error(), so it's important to understand what types of errors we're dealing with. Can you give more detail about these invalid parameter errors, or a few examples? The proposed patch below: It would be helpful to see a ChangeLog entry for the patch. Thanks Martin
[jira] Created: (STDCXX-461) Error in formatting of infinity
Error in formatting of infinity
Key: STDCXX-461
URL: https://issues.apache.org/jira/browse/STDCXX-461
Project: C++ Standard Library
Issue Type: Bug
Components: 27. Input/Output
Reporter: Jeremy Dean
Priority: Minor
referrenced in e-mail thread:
http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200706.mbox/ajax/[EMAIL
PROTECTED]
But the test program does demonstrate a real problem, and that is the
formatting of infinity when the stream precision is greater than 7. It looks as
though the num_put facet inserts the string inf\0\0ity into the stream rather
than inf.
$ cat u.cpp make u ./u | od -c
#include cassert
#include iostream
#include sstream
int main () {
std::ostringstream s;
s.precision (8);
s 1 / 0.0;
std::cout s.str () '\n';
assert (s.str () == inf);
}
gcc -c -I/build/sebor/stdcxx/include/ansi -D_RWSTDDEBUG -D_RWSTD_USE_CONFIG
-I/build/sebor/stdcxx/include -I/build/sebor/stdcxx-gcc-4.1.0-11s/include
-I/build/sebor/stdcxx/examples/include -pedantic -nostdinc++ -g -W
-Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long u.cpp
u.cpp: In function 'int main()':
u.cpp:8: warning: division by zero in '1 / 0.'
gcc u.o -o u -L/build/sebor/stdcxx-gcc-4.1.0-11s/lib -lstd11s -lsupc++ -lm
Assertion failed: s.str () == inf, file u.cpp, line 10
000 i n f \0 \0 i t y \n
011
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-462) std::time_get example exposes undefined behavior
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.2, 4.1.3 Reporter: Martin Sebor Priority: Critical 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.
