RE: STDCXX examples fails and reasons [MSVC]
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Monday, July 09, 2007 7:47 AM To: stdcxx-dev@incubator.apache.org Subject: Re: STDCXX examples fails and reasons [MSVC] 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. Hmm. I don't suppose it should matter (our tests shouldn't be relying on the variable being set to any specific value), but I see what you mean. Is there a way to set the variable just for examples? I don't know another way, but I'm not a makefile guru :) Commited thus: http://svn.apache.org/viewvc?view=revrev=554682 Farid.
Re: STDCXX examples fails and reasons [MSVC]
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Monday, July 09, 2007 7:47 AM To: stdcxx-dev@incubator.apache.org Subject: Re: STDCXX examples fails and reasons [MSVC] 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. Hmm. I don't suppose it should matter (our tests shouldn't be relying on the variable being set to any specific value), but I see what you mean. Is there a way to set the variable just for examples? I don't know another way, but I'm not a makefile guru :) In GNU make there is such a thing as Target-Specific Variables. I thought maybe we could use it to set TZ in GNUmakefile.exm: http://www.gnu.org/software/make/manual/make.html#Target_002dspecific Martin
Re: STDCXX examples fails and reasons [MSVC]
Farid Zaripov wrote: -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. Hmm. I don't suppose it should matter (our tests shouldn't be relying on the variable being set to any specific value), but I see what you mean. Is there a way to set the variable just for examples? Martin 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: 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: 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.
RE: STDCXX examples fails and reasons [MSVC]
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Friday, June 22, 2007 5:58 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] [...] limits.cpp should produce the qnan for Quiet NAN and snan for Signaling NAN on all platforms. I can't find this requirement in standard. It's not in the C++ standard but it is in C99, under fprintf(), the f and F conversion specifier: A double argument representing an infinity is converted in one of the styles [-]inf or [-]infinity - which style is implementation-defined. A double argument representing a NaN is converted in one of the styles [-]nan or [-]nan(n-char-sequence) - which style, and the meaning of any n-char-sequence, is implementation-defined. The F conversion specifier produces INF, INFINITY, or NAN instead of inf, infinity, or nan, respectively. Ok, thanks. Could you share the C99 standard? Farid.
RE: STDCXX examples fails and reasons [MSVC]
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Monday, June 25, 2007 7:41 PM To: stdcxx-dev@incubator.apache.org Subject: Re: STDCXX examples fails and reasons [MSVC] 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. Ok, ok. It's impossible. ^) 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. Done: http://svn.apache.org/viewvc?view=revrev=550774 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.
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 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: 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] [...] limits.cpp should produce the qnan for Quiet NAN and snan for Signaling NAN on all platforms. I can't find this requirement in standard. The MSVC/Dinkumware STL produces: static double infinity () = 1.#INF; static double quiet_NaN () = 1.#QNAN; static double signaling_NaN () = 1.#QNAN; The gcc 3.4.4/SGI STL/Cygwin produces: static double infinity () = inf; static double quiet_NaN () = nan; static double signaling_NaN () = nan; 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] [...] 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). 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. The same situation with ~time_get_byname(), ~time_put(), ~time_put_byname(). Farid.
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] [...] limits.cpp should produce the qnan for Quiet NAN and snan for Signaling NAN on all platforms. I can't find this requirement in standard. It's not in the C++ standard but it is in C99, under fprintf(), the f and F conversion specifier: A double argument representing an infinity is converted in one of the styles [-]inf or [-]infinity — which style is implementation-defined. A double argument representing a NaN is converted in one of the styles [-]nan or [-]nan(n-char-sequence) — which style, and the meaning of any n-char-sequence, is implementation-defined. The F conversion specifier produces INF, INFINITY, or NAN instead of inf, infinity, or nan, respectively. 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_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. 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? 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? Martin
RE: STDCXX examples fails and reasons [MSVC]
-Original Message- From: Farid Zaripov [mailto:[EMAIL PROTECTED] Sent: Friday, June 22, 2007 7:30 PM 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. I've forget to specify the URL with changes: http://svn.apache.org/viewvc?view=revrev=549865 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]
[...]
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:
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.
Re: STDCXX examples fails and reasons [MSVC]
Farid Zaripov wrote: The list of the fails and reasons here: http://people.apache.org/~faridz/examples.html Thanks! I think that OUTPUT status is not a fail (and examples with that status are not counted as failed in unix-like platforms, but they are counted as failed on Windows platform except cygwin). Oh. We need to fix that. The OUTPUT state is just a note that there is no reference output to compare the actual output against. The examples that have no reference output file are designed to produce platform-specific output. We should try to limit such examples as much as possible but in some cases (such as limits.cpp) it's not entirely possible. I've fixed the fail reasons of the messages example: http://svn.apache.org/viewvc?view=revrev=549546 http://svn.apache.org/viewvc?view=revrev=549550 Great! For the rest, we should open issues in Jira so we don't forget to get back to them. limits.cpp should produce the qnan for Quiet NAN and snan for Signaling NAN on all platforms. (We already have an issue for rwexcept: STDCXX-293). time_get looks like a bug (or lack of functionality) in our library, and 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. 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. Martin
