[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_get &tg =
>> std::use_facet >(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.
[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
#include
#include
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.
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
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: 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 << "Something " << std::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: 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
#include
#include
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
#include
#include
#include
#include
#include
void test1() {
std::ostringstream S;
long double x = std::pow(1e300,2);
S << "Something " << std::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: 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: 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: 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: Getting incorrect behavior on strstream
> -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 https://msdn2.microsoft.com/en-us/library/k1z9z9cf(VS.80).aspx Farid.
Convert MSVC CRT debug reports to rwtest driver debug reports
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.
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()).
The proposed patch below:
Index: driver.cpp
===
--- driver.cpp (revision 550382)
+++ driver.cpp (working copy)
@@ -69,6 +69,10 @@
# define _RWSTD_NO_ISATTY
#endif // _WIN{32,64}
+#ifdef _MSC_VER
+#include// for _CrtSetReportHook()
+#endif // _MSC_VER
+
// expand _TEST_EXPORT macros
#define _RWSTD_TEST_SRC
#include
@@ -1118,6 +1122,47 @@
/***
*/
+#ifdef _MSC_VER
+
+#if _MSC_VER >= 1400
+static void
+_rw_invalid_parameter(const wchar_t * expression,
+ const wchar_t * function,
+ const wchar_t * file,
+ unsigned int line,
+ uintptr_t pReserved)
+{
+#ifdef _DEBUG
+rw_note (0, __FILE__, __LINE__,
+ "Invalid parameter in function %ls.\nFile: %ls Line: %u\n"
+ "Expression: %ls", function, file, line, expression);
+#endif
+}
+#endif // _MSC_VER >= 1400
+
+
+static int
+_rw_report_hook (int type, char *msg, int *ret)
+{
+typedef int (* rw_report) (int, const char *, int, const char *,
...);
+rw_report rw_reports [] = { rw_warn, rw_error, rw_assert };
+
+RW_ASSERT (0 <= type && sizeof (rw_reports) / sizeof (*rw_reports)
> type);
+
+// remove trailing new line
+const size_t len = strlen (msg);
+if (len && '\n' == msg [len - 1])
+msg [len - 1] = '\0';
+
+*ret = rw_reports [type] (0, __FILE__, __LINE__, "%s", msg);
+
+return 1; // 1 == TRUE
+}
+
+#endif // _MSC_VER
+
+/**
**/
+
_TEST_EXPORT int
rw_test (int argc, char **argv,
const char *fname,
@@ -1127,6 +1172,13 @@
const char *optstr,
...)
{
+#ifdef _MSC_VER
+# if _MSC_VER >= 1400
+_set_invalid_parameter_handler (_rw_invalid_parameter);
+# endif // _MSC_VER >= 1400
+_CrtSetReportHook (_rw_report_hook);
+#endif // _MSC_VER
+
CHECK_INIT (false, "rw_test()");
va_list va;
Farid.
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_get &tg =
std::use_facet >(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: 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]
> -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_get &tg =
std::use_facet >(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 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.
[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.
[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-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.
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
RE: STD_BAD_ALLOC.cpp test problem on Windows
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Tuesday, June 19, 2007 6:52 AM > To: stdcxx-dev@incubator.apache.org > Subject: Re: STD_BAD_ALLOC.cpp test problem on Windows > > I think this will work. > > Just as a side-note (I think you're handling this case > safely) there is a potential problem here since headers > aren't checked for dependencies on config macros and so > testing their value in them is unsafe unless it has been > first tested in the .cpp file that #includes the header. The > duplication can lead to hard to find errors. > > So while your changes are safe (AFAICT) I would suggest a > comment just before the #include directive for proclimits.h > mentioning this caveat and a similar one in the header itself. Done: http://svn.apache.org/viewvc?view=rev&rev=548616 Farid.
