You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Farid Zaripov <Fa...@epam.com> on 2007/06/21 19:20:20 UTC
STDCXX examples fails and reasons [MSVC]
The list of the fails and reasons here:
http://people.apache.org/~faridz/examples.html
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).
I've fixed the fail reasons of the messages example:
http://svn.apache.org/viewvc?view=rev&rev=549546
http://svn.apache.org/viewvc?view=rev&rev=549550
Farid.
RE: STDCXX examples fails and reasons [MSVC]
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Farid Zaripov [mailto:Farid_Zaripov@epam.com]
> 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=rev&rev=549865
Farid.
Re: STDCXX examples fails and reasons [MSVC]
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:msebor@gmail.com] 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]
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:msebor@gmail.com] 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=rev&rev=554682
Farid.
Re: STDCXX examples fails and reasons [MSVC]
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:msebor@gmail.com] 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]
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:msebor@gmail.com] 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]
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> 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]
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> 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]
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> 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:sebor@roguewave.com]
> >> 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]
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> 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]
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> 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]
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> 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]
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> 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=rev&rev=550774
Farid.
Re: STDCXX examples fails and reasons [MSVC]
Posted by Martin Sebor <se...@roguewave.com>.
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<char, Iter> &tg =
> std::use_facet<std::time_get<char, 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]
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> 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:sebor@roguewave.com]
> >> 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<char, Iter> &tg =
std::use_facet<std::time_get<char, 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]
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> 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]
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> 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]
Posted by Martin Sebor <se...@roguewave.com>.
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=rev&rev=549546
> http://svn.apache.org/viewvc?view=rev&rev=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