Re: _RWSTD_VER value on trunk
Travis Vitek wrote: Martin Sebor wrote: Travis Vitek wrote: Martin Sebor wrote: This has been bugging me -- when someone checks out trunk, does a build and sends us build results, we have no way of telling that the build results are, in fact, for trunk and not for 4.2.0 (or the head of 4.2.x), because the value of _RWSTD_VER is the same. I think we should change it so that the value is unique for each branch, or at least distinct from any release. Any suggestions for what would be a good value? Martin, If all you care about is detecting what branch the results are for, why can't we just dump $HeadURL$ of the GNUmakefile to the top of the build results? Yes, I think that's what Mark meant. I like the idea I just wasn't sure I wasn't missing some downside since we'd be taking the macro out of $TOPDIR/include/rw/_config.h and moving it to the generated config header in $BUILDDIR. I.e., it won't be possible to grep for the macro in the freshly downloaded/extracted sources to find the version -- see my comments below: http://www.nabble.com/Re%3A-_RWSTD_VER-value-on-trunk-p14340222.html But unless someone does come up with a problem I'll go ahead and cook up something along these lines. Martin I think you are taking this a bit further than I am talking about. In your original post you say we don't really have no way to tell which branch the user did their build from. I'm saying just add a target to the GNUmakefile that dumps the expanded $HeadURL$ string, and then use it in the build process. We also need to #define the _RWSTD_VER macro so that users can use it in preprocessor conditionals. But the idea is essentially the same: GNUmakefile.cfg would take the value of $HeadURL$, extract the part that contains the version if it's there or "trunk," and append the result to the generate config.h in the form of a couple of macro #definitions, one for _RWSTD_VER and one for _RWSTD_VER_STR (in addition to using it in the name of the [shared] library). Or is this not what you're talking about? It sounds like you are trying to establish a strict mapping between the library version and where the sources are kept in subversion. That's right. The version reported by a checkout of branches/4.2.x would be "4.2.x" (and _RWSTD_VER & 0xff00 would have to be something like 0xff00, to borrow Andrew's convention). Which would reinforce the guideline that a branch should never be released (tags are). The version reported by a checkout of tags/4.2.1 would be 4.2.1. What do other subversion projects do about this? Good question! Let's find out. I know gcc uses macros defined in its makefiles but I don't know how the macro values are derived. It seems that this wouldn't be a problem if we had a 4.2.1 branch and we could 'encourage' users to leave the intermediate branches [the ones used for merging] alone. Exactly. Except it's not called a branch but a tag. Martin
Re: _RWSTD_VER value on trunk
Martin Sebor wrote: > > Travis Vitek wrote: >> >> >> Martin Sebor wrote: >>> This has been bugging me -- when someone checks out trunk, does a build >>> and sends >>> us build results, we have no way of telling that the build results are, >>> in >>> fact, for trunk and >>> not for 4.2.0 (or the head of 4.2.x), because the value of _RWSTD_VER is >>> the same. I >>> think we should change it so that the value is unique for each branch, >>> or >>> at least distinct >>> from any release. >>> >>> Any suggestions for what would be a good value? >>> >> >> Martin, >> >> If all you care about is detecting what branch the results are for, why >> can't we just dump $HeadURL$ of the GNUmakefile to the top of the build >> results? > > Yes, I think that's what Mark meant. I like the idea I just wasn't > sure I wasn't missing some downside since we'd be taking the macro > out of $TOPDIR/include/rw/_config.h and moving it to the generated > config header in $BUILDDIR. I.e., it won't be possible to grep for > the macro in the freshly downloaded/extracted sources to find the > version -- see my comments below: > http://www.nabble.com/Re%3A-_RWSTD_VER-value-on-trunk-p14340222.html > > But unless someone does come up with a problem I'll go ahead and > cook up something along these lines. > > Martin > I think you are taking this a bit further than I am talking about. In your original post you say we don't really have no way to tell which branch the user did their build from. I'm saying just add a target to the GNUmakefile that dumps the expanded $HeadURL$ string, and then use it in the build process. It sounds like you are trying to establish a strict mapping between the library version and where the sources are kept in subversion. What do other subversion projects do about this? It seems that this wouldn't be a problem if we had a 4.2.1 branch and we could 'encourage' users to leave the intermediate branches [the ones used for merging] alone. Travis -- View this message in context: http://www.nabble.com/Re%3A-svn-commit%3A-r597396incubator-stdcxx-branches-4.2.x-tests-numerics-26.valarray.cassign.cpp-tp13905517p14410574.html Sent from the stdcxx-dev mailing list archive at Nabble.com.
[jira] Issue Comment Edited: (STDCXX-605) [IBM XLC++] errors compiling dynatype.cpp
[
https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553208
]
vitek edited comment on STDCXX-605 at 12/18/07 6:49 PM:
---
In the failure you mention, the conversion we want is to `const int&'. The
conversion operator that gets invoked is the non-const `operator T&' with 'T'
being 'const int'. That conversion operator calls the non-const retrieve(),
which keeps the const and looks in the static dynatype::map for a
value. We should be looking in dynatype::map, but the const is not being
stripped.
Consider the following...
struct S
{
private:
template int g (T*) { return 0; }
template int g (const T*) const { return 1; }
public:
template int f () { return g ((T*)0); }
};
int main ()
{
const int a = S().f();
const int b = S().f();
return (a << 1) | b;
}
I believe that the expected result is 0. When compiling the S().f(),
I see a few candidate functions for overload resolution. Given that the
overload resolution system treats member functions as if they were free
functions with a correctly cv-qualified implicit object parameter, the
candidates would seem to be
int S_g(S&, int*);
int S_g(S&, const int*);
from the first template, and
int S_g(const S&, const int*);
from the second. The actual type of the call is
??? S_g(S&, const int*);
So the best match is easily selected, and the result is a call to the non-const
'g' template, which leaves the const on the template type T instead of
stripping it like we want.
Continuing with the example, I see a few options. We could make both 'g'
overloads share the same constness. If we make them have the same constness,
then the overload resolution chooses the best match based on the explicit
parameter type, and then discards const as we want. The disadvantage of this is
that we would either have two const overloads of 'g' [which you didn't appear
to like], or we can have two non-const overloads and cast away const when
calling from a const member function. A third option would be to make both 'g'
overloads into non-member functions that takes const S* [essentially the same
as making both members const], but that would require some code rearranging.
Personally I thought that the two const retrieve() overloads was the simplest
and cleanest solution [stdcxx-605-v2.patch]. The most recent patch involves
changing fewer lines of code in the example, but it leaves a nasty static/const
cast [stdcxx-605-v1.patch].
was (Author: vitek):
In the failure you mention, the conversion we want is to `const int&'. The
conversion operator that gets invoked is the non-const `operator T&' with 'T'
being 'const int'. That conversion operator calls the non-const retrieve(),
which keeps the const and looks in the static dynatype::map for a
value. We should be looking in dynatype::map, but the const is not being
stripped.
Consider the following...
struct S
{
private:
template int g (T*) { return 0; }
template int g (const T*) const { return 1; }
public:
template int f () { return g ((T*)0); }
};
int main ()
{
const int a = S().f();
const int b = S().f();
return (a << 1) | b;
}
I believe that the expected result is 0. When compiling the S().f(),
I see a few candidate functions for overload resolution. Given that the
overload resolution system treats member functions as if they were free
functions with a correctly cv-qualified implicit object parameter, the
candidates would seem to be
int S_g(S&, int*);
int S_g(S&, const int*);
from the first template, and
int S_g(const S&, int*);
int S_g(const S&, const int*);
from the second. The actual type of the call is
??? S_g(S&, const int*);
So the best match is easily selected, and the result is a call to the non-const
'g' template, which leaves the const on the template type T instead of
stripping it like we want.
Continuing with the example, I see a few options. We could make both 'g'
overloads share the same constness. If we make them have the same constness,
then the overload resolution chooses the best match based on the explicit
parameter type, and then discards const as we want. The disadvantage of this is
that we would either have two const overloads of 'g' [which you didn't appear
to like], or we can have two non-const overloads and cast away const when
calling from a const member function. A third option would be to make both 'g'
overloads into non-member functions that takes const S* [essentially the same
as making both members const], but that would require some code rearranging.
Personally I thought that the two const retrieve() overloads was the simplest
and cleanest solution [stdcxx-605-v2.patch]. The most recent patch involves
changing fewer lines of code in the example, but it leaves a nasty static/const
cast [stdcxx-605-v1.pat
[jira] Updated: (STDCXX-605) [IBM XLC++] errors compiling dynatype.cpp
[ https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-605: Attachment: stdcxx-605-out.patch The update output is now attached as a separate patch. > [IBM XLC++] errors compiling dynatype.cpp > - > > Key: STDCXX-605 > URL: https://issues.apache.org/jira/browse/STDCXX-605 > Project: C++ Standard Library > Issue Type: Bug > Components: Examples >Affects Versions: 4.2.0 > Environment: XLC++ 6.0 through 9.0/AIX 5.3 >Reporter: Martin Sebor >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-605-out.patch, stdcxx-605-v1.patch, > stdcxx-605-v2.patch > > > The dynatype.cpp example program fails to compile with IBM XLC++ 9.0 on AIX > with ethe following errors: > xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include > -I$(BUILDDIR)/include -I$(TOPDIR)/examples/include -O -Q > -qtemplateregistry=dynatype.ti $(TOPDIR)/examples/tutorial/dynatype.cpp > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 203.27: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "int". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 209.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 215.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 222.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 228.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 238.28: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "char". > gmake: *** [dynatype.o] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [PATCH] rw_snprintf doesn't null terminate strings
Travis Vitek wrote:
>
>
> If rw_snprintf() is intended to behave like sprintf(), it should probably
> append the null terminator. If not, I should probably revise my fix to
> STDCXX-524 [https://issues.apache.org/jira/browse/STDCXX-524].
>
>
I think it should but the patch doesn't actually make it do that. I wrote a
small
test case to check (see below). here are the results with the patch:
rw_snprintf(0, "0123") ==> 4: ""
snprintf (0, "0123") ==> 4: ""
rw_snprintf(1, "0123") ==> 4: ""
snprintf (1, "0123") ==> 4: "\0***"
rw_snprintf(2, "0123") ==> 4: ""
snprintf (2, "0123") ==> 4: "0\0**"
rw_snprintf(3, "0123") ==> 4: ""
snprintf (3, "0123") ==> 4: "01\0*"
rw_snprintf(4, "0123") ==> 4: ""
snprintf (4, "0123") ==> 4: "012\0"
rw_snprintf(5, "0123") ==> 4: "0123\0***"
snprintf (5, "0123") ==> 4: "0123\0***"
rw_snprintf(6, "0123") ==> 4: "0123\0***"
snprintf (6, "0123") ==> 4: "0123\0***"
I committed a slightly different patch the does what I think we want:
http://svn.apache.org/viewvc?rev=605389&view=rev
Let me know if you see a problem with it.
Martin
>
> Travis
>
>
> Index: printf.cpp
> ===
> --- printf.cpp(revision 605328)
> +++ printf.cpp(working copy)
> @@ -3376,8 +3376,10 @@
>
> va_end (va);
>
> -if (size_t (nchars) <= bufsize)
> +if (size_t (nchars) < bufsize) {
> memcpy (buf, tmpbuf, size_t (nchars));
> +buf [nchars] = 0;
> +}
>
> free (tmpbuf);
>
#include
#include
void test (int n, const char *s)
{
char buf1[8] = { '*', '*', '*', '*', '*', '*', '*', '*' };
char buf2[8] = { '*', '*', '*', '*', '*', '*', '*', '*' };
int m;
m = rw_snprintf (buf1, n, s);
rw_printf ("rw_snprintf(%d, %#s) ==> %d: %{#*s}\n",
n, s, m, int (sizeof buf1), buf1);
m = snprintf (buf2, n, s);
rw_printf ("snprintf (%d, %#s) ==> %d: %{#*s}\n",
n, s, m, int (sizeof buf2), buf2);
}
int main ()
{
test (0, "0123");
test (1, "0123");
test (2, "0123");
test (3, "0123");
test (4, "0123");
test (5, "0123");
test (6, "0123");
}
--
View this message in context:
http://www.nabble.com/-PATCH--rw_snprintf-doesn%27t-null-terminate-strings-tp14407607p14410127.html
Sent from the stdcxx-dev mailing list archive at Nabble.com.
[jira] Updated: (STDCXX-605) [IBM XLC++] errors compiling dynatype.cpp
[
https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Travis Vitek updated STDCXX-605:
Attachment: stdcxx-605-v2.patch
stdcxx-605-v1.patch
In the failure you mention, the conversion we want is to `const int&'. The
conversion operator that gets invoked is the non-const `operator T&' with 'T'
being 'const int'. That conversion operator calls the non-const retrieve(),
which keeps the const and looks in the static dynatype::map for a
value. We should be looking in dynatype::map, but the const is not being
stripped.
Consider the following...
struct S
{
private:
template int g (T*) { return 0; }
template int g (const T*) const { return 1; }
public:
template int f () { return g ((T*)0); }
};
int main ()
{
const int a = S().f();
const int b = S().f();
return (a << 1) | b;
}
I believe that the expected result is 0. When compiling the S().f(),
I see a few candidate functions for overload resolution. Given that the
overload resolution system treats member functions as if they were free
functions with a correctly cv-qualified implicit object parameter, the
candidates would seem to be
int S_g(S&, int*);
int S_g(S&, const int*);
from the first template, and
int S_g(const S&, int*);
int S_g(const S&, const int*);
from the second. The actual type of the call is
??? S_g(S&, const int*);
So the best match is easily selected, and the result is a call to the non-const
'g' template, which leaves the const on the template type T instead of
stripping it like we want.
Continuing with the example, I see a few options. We could make both 'g'
overloads share the same constness. If we make them have the same constness,
then the overload resolution chooses the best match based on the explicit
parameter type, and then discards const as we want. The disadvantage of this is
that we would either have two const overloads of 'g' [which you didn't appear
to like], or we can have two non-const overloads and cast away const when
calling from a const member function. A third option would be to make both 'g'
overloads into non-member functions that takes const S* [essentially the same
as making both members const], but that would require some code rearranging.
Personally I thought that the two const retrieve() overloads was the simplest
and cleanest solution [stdcxx-605-v2.patch]. The most recent patch involves
changing fewer lines of code in the example, but it leaves a nasty static/const
cast [stdcxx-605-v1.patch].
> [IBM XLC++] errors compiling dynatype.cpp
> -
>
> Key: STDCXX-605
> URL: https://issues.apache.org/jira/browse/STDCXX-605
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Examples
>Affects Versions: 4.2.0
> Environment: XLC++ 6.0 through 9.0/AIX 5.3
>Reporter: Martin Sebor
>Assignee: Travis Vitek
> Fix For: 4.2.1
>
> Attachments: stdcxx-605-v1.patch, stdcxx-605-v2.patch
>
>
> The dynatype.cpp example program fails to compile with IBM XLC++ 9.0 on AIX
> with ethe following errors:
> xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include
> -I$(BUILDDIR)/include -I$(TOPDIR)/examples/include -O -Q
> -qtemplateregistry=dynatype.ti $(TOPDIR)/examples/tutorial/dynatype.cpp
> "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 203.27: 1540-0216 (S) An
> expression of type "dynatype" cannot be converted to type "int".
> "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 209.30: 1540-0216 (S) An
> expression of type "dynatype" cannot be converted to type "double".
> "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 215.30: 1540-0216 (S) An
> expression of type "dynatype" cannot be converted to type "double".
> "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 222.35: 1540-0216 (S) An
> expression of type "dynatype" cannot be converted to type "const char *".
> "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 228.35: 1540-0216 (S) An
> expression of type "dynatype" cannot be converted to type "const char *".
> "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 238.28: 1540-0216 (S) An
> expression of type "dynatype" cannot be converted to type "char".
> gmake: *** [dynatype.o] Error 1
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-605) [IBM XLC++] errors compiling dynatype.cpp
[ https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-605: Attachment: (was: stdcxx-605.patch) > [IBM XLC++] errors compiling dynatype.cpp > - > > Key: STDCXX-605 > URL: https://issues.apache.org/jira/browse/STDCXX-605 > Project: C++ Standard Library > Issue Type: Bug > Components: Examples >Affects Versions: 4.2.0 > Environment: XLC++ 6.0 through 9.0/AIX 5.3 >Reporter: Martin Sebor >Assignee: Travis Vitek > Fix For: 4.2.1 > > > The dynatype.cpp example program fails to compile with IBM XLC++ 9.0 on AIX > with ethe following errors: > xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include > -I$(BUILDDIR)/include -I$(TOPDIR)/examples/include -O -Q > -qtemplateregistry=dynatype.ti $(TOPDIR)/examples/tutorial/dynatype.cpp > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 203.27: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "int". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 209.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 215.30: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "double". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 222.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 228.35: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "const char *". > "$(TOPDIR)/examples/tutorial/dynatype.cpp", line 238.28: 1540-0216 (S) An > expression of type "dynatype" cannot be converted to type "char". > gmake: *** [dynatype.o] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
forgotten password
I was recently asked how to go about getting a forgotten password reset. I thought I'd post the answer(s) here in case someone needs this info in the future: If you forgot you svn password here's an FAQ that might help: http://www.apache.org/dev/committers.html#svn-authorization-failure Otherwise, if you forgot your UNIX password, read this: http://www.apache.org/dev/reporting-issues.html#new-committer I.e., send an email to [EMAIL PROTECTED] to get the password reset and CC [EMAIL PROTECTED] while we're still in the incubator, and to [EMAIL PROTECTED] when we're out. In case it's not clear, the a.o above stands for apache.org. Martin
[jira] Updated: (STDCXX-684) auto-detect _RWSTD_VER value from branch/file name
[ https://issues.apache.org/jira/browse/STDCXX-684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-684: Summary: auto-detect _RWSTD_VER value from branch/file name (was: ato-detect _RWSTD_VER value from branch/file name) > auto-detect _RWSTD_VER value from branch/file name > -- > > Key: STDCXX-684 > URL: https://issues.apache.org/jira/browse/STDCXX-684 > Project: C++ Standard Library > Issue Type: New Feature > Components: Configuration >Affects Versions: 4.2.0 >Reporter: Martin Sebor >Priority: Minor > > As suggested in the thread below, it would be useful to a) guarantee that the > value of the _RWSTD_VER macro is unique to each branch and trunk, and b) to > let the library configuration infrastructure automatically figure out the > value from the name of the branch the file came from, e.g., by manipulating > the value of the $HeadURL$ Subversion keyword. > http://www.nabble.com/Re-3A-svn-commit-3A-r597396incubator-stdcxx-branches-4.2.x-tests-numerics-26.valarray.cassign.cpp-to13905517.html#a14289920 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-684) ato-detect _RWSTD_VER value from branch/file name
ato-detect _RWSTD_VER value from branch/file name - Key: STDCXX-684 URL: https://issues.apache.org/jira/browse/STDCXX-684 Project: C++ Standard Library Issue Type: New Feature Components: Configuration Affects Versions: 4.2.0 Reporter: Martin Sebor Priority: Minor As suggested in the thread below, it would be useful to a) guarantee that the value of the _RWSTD_VER macro is unique to each branch and trunk, and b) to let the library configuration infrastructure automatically figure out the value from the name of the branch the file came from, e.g., by manipulating the value of the $HeadURL$ Subversion keyword. http://www.nabble.com/Re-3A-svn-commit-3A-r597396incubator-stdcxx-branches-4.2.x-tests-numerics-26.valarray.cassign.cpp-to13905517.html#a14289920 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-683) implement notion of expected failures in the test suite
implement notion of expected failures in the test suite --- Key: STDCXX-683 URL: https://issues.apache.org/jira/browse/STDCXX-683 Project: C++ Standard Library Issue Type: New Feature Components: Test Driver, Tests Affects Versions: 4.2.0 Reporter: Martin Sebor Priority: Critical Tests (or examples) that fail for known reasons that we haven't been able to deal with should be distinguished from failures that haven't been analyzed yet. For example, an example program that fails to compile on an older target platform because of a compiler bug that we can't find a simple/elegant workaround should be flagged as such in the test results. Similarly, a test that fails one or more assertions due to compiler or libc bugs on a specific platform (or a set of platforms) that we are unable to work around should be reported as such. This is important in order to reduce the currently fairly large number of unexpected failures and to be able to make changes without having to worry about regressions as much. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: _RWSTD_VER value on trunk
Travis Vitek wrote: Martin Sebor wrote: This has been bugging me -- when someone checks out trunk, does a build and sends us build results, we have no way of telling that the build results are, in fact, for trunk and not for 4.2.0 (or the head of 4.2.x), because the value of _RWSTD_VER is the same. I think we should change it so that the value is unique for each branch, or at least distinct from any release. Any suggestions for what would be a good value? Martin, If all you care about is detecting what branch the results are for, why can't we just dump $HeadURL$ of the GNUmakefile to the top of the build results? Yes, I think that's what Mark meant. I like the idea I just wasn't sure I wasn't missing some downside since we'd be taking the macro out of $TOPDIR/include/rw/_config.h and moving it to the generated config header in $BUILDDIR. I.e., it won't be possible to grep for the macro in the freshly downloaded/extracted sources to find the version -- see my comments below: http://www.nabble.com/Re%3A-_RWSTD_VER-value-on-trunk-p14340222.html But unless someone does come up with a problem I'll go ahead and cook up something along these lines. Martin
[jira] Created: (STDCXX-682) move build result pages from ~sebor to the stdcxx site
move build result pages from ~sebor to the stdcxx site -- Key: STDCXX-682 URL: https://issues.apache.org/jira/browse/STDCXX-682 Project: C++ Standard Library Issue Type: Task Components: Web Reporter: Martin Sebor The nightly build result pages currently stored in http://people.apache.org/~sebor/ need to be moved to some project-specific directory, such as http://incubator.apache.org/stdcxx/ is now. This should be done after the stdcxx has been moved to its final location as a Top Level Project, i.e., after INFRA-1425 has been resolved. Currently, stdcxx build results for trunk are stored at the following locations: http://people.apache.org/~sebor/stdcxx/results http://people.apache.org/~sebor/stdcxx/results/builds and those for stdcxx-4.2.0 are here: http://people.apache.org/~sebor/stdcxx-4.2.0/results/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: _RWSTD_VER value on trunk (was: Re: svn commit: r597396 - /incubator/stdcxx/branches/4.2.x/tests/numerics/26.valarray.cassign.cpp)
Martin Sebor wrote: > > This has been bugging me -- when someone checks out trunk, does a build > and sends > us build results, we have no way of telling that the build results are, in > fact, for trunk and > not for 4.2.0 (or the head of 4.2.x), because the value of _RWSTD_VER is > the same. I > think we should change it so that the value is unique for each branch, or > at least distinct > from any release. > > Any suggestions for what would be a good value? > Martin, If all you care about is detecting what branch the results are for, why can't we just dump $HeadURL$ of the GNUmakefile to the top of the build results? Travis -- View this message in context: http://www.nabble.com/Re%3A-svn-commit%3A-r597396incubator-stdcxx-branches-4.2.x-tests-numerics-26.valarray.cassign.cpp-tp13905517p14408307.html Sent from the stdcxx-dev mailing list archive at Nabble.com.
[jira] Commented: (STDCXX-675) [MSVC] implement autolinking feature
[ https://issues.apache.org/jira/browse/STDCXX-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552933 ] Travis Vitek commented on STDCXX-675: - If the new user takes advantage of the autolinking feature, they will have to modify their build system to get it to work with a previous version of the library. i.e. they will need to explicitly link the library file when they go back to 4.2.0. Will this ever be useful for any compiler other than MSVC and ICC/Windows? Is there a way that we can ensure the user links the right library on all platforms? This wouldn't avoid the need to explicitly link the library, but it would eliminate issues with linking the wrong library. > [MSVC] implement autolinking feature > > > Key: STDCXX-675 > URL: https://issues.apache.org/jira/browse/STDCXX-675 > Project: C++ Standard Library > Issue Type: Improvement > Components: Configuration >Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 > Environment: MSVC, ICC/Windows >Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Trivial > Fix For: 4.2.1 > > Attachments: autolink.patch > > > At the moment the users of the library should explicitly specify the used > library name in linker command line. Here might be problems if the user's > project was compiled with config.h for some configuration (let's say 12d) but > linked with library for another configuration (i.e. libstd12s.lib). > The MSVC and ICC/Windows has the posibility to specify the library using > #pragma comment (lib, libname) directive. So #including any header from the > library will leads to linking automatically with the proper library file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-614) [gcc 4.1/Linux] error on size_t in 27.stringbuf.xsputn.stdcxx-515.cpp
[ https://issues.apache.org/jira/browse/STDCXX-614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek closed STDCXX-614. --- Resolution: Fixed Verified in automated testing. > [gcc 4.1/Linux] error on size_t in 27.stringbuf.xsputn.stdcxx-515.cpp > - > > Key: STDCXX-614 > URL: https://issues.apache.org/jira/browse/STDCXX-614 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.2.0 > Environment: gcc 4.1.1 on Red Hat Enterprise Linux Server release 5 > (Tikanga) >Reporter: Martin Sebor >Assignee: Travis Vitek >Priority: Minor > Fix For: 4.2.1 > > > The 27.stringbuf.xsputn.stdcxx-515.cpp fails to compile with gcc 4.1.1 on > Red Hat Enterprise Linux Server release 5 with the error below: > gcc -c -I$(TOPDIR)/include/ansi -D_RWSTDDEBUG-I$(TOPDIR)/include > -I$(BUILDDIR)/include -I$(TOPDIR)/tests/include -pedantic -nostdinc++ -g > -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long > -Wcast-align $(TOPDIR)/tests/regress/27.stringbuf.xsputn.stdcxx-515.cpp > $(TOPDIR)/tests/regress/27.stringbuf.xsputn.stdcxx-515.cpp: In function 'int > main()': > $(TOPDIR)/tests/regress/27.stringbuf.xsputn.stdcxx-515.cpp:33: error: > 'size_t' was not declared in this scope > $(TOPDIR)/tests/regress/27.stringbuf.xsputn.stdcxx-515.cpp:33: error: > expected `;' before 'i' > $(TOPDIR)/tests/regress/27.stringbuf.xsputn.stdcxx-515.cpp:33: error: 'i' was > not declared in this scope > gmake: *** [27.stringbuf.xsputn.stdcxx-515.o] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-664) [IBM XLC++ 9.0/AIX 5.3] SIGABRT in 22.locale.globals.mt
[
https://issues.apache.org/jira/browse/STDCXX-664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Travis Vitek closed STDCXX-664.
---
Resolution: Fixed
Test passing automated testing.
> [IBM XLC++ 9.0/AIX 5.3] SIGABRT in 22.locale.globals.mt
> ---
>
> Key: STDCXX-664
> URL: https://issues.apache.org/jira/browse/STDCXX-664
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Tests
>Affects Versions: 4.2.0
>Reporter: Travis Vitek
>Assignee: Travis Vitek
> Fix For: 4.2.1
>
> Attachments: stdcxx-664-1.patch, stdcxx-664-2.patch
>
>
> Appears to affect single-threaded bulids only.
> [EMAIL PROTECTED] tests]$ ./22.locale.globals.mt
> # INFO (S1) (10 lines):
> # TEXT:
> # COMPILER: IBM VisualAge C++, __IBMCPP__ = 900
> # ENVIRONMENT: powerpc running aix-5.3
> # FILE: 22.locale.globals.mt.cpp
> # COMPILED: Nov 8 2007, 21:35:16
> # COMMENT: thread safety
>
> # CLAUSE: lib.locale.global.templates
> # NOTE (S2) (5 lines):
> # TEXT: executing "locale -a > /tmp/tmpfile-fK3jqa"
> # CLAUSE: lib.locale.global.templates
> # FILE: process.cpp
> # LINE: 270
> # INFO (S1) (3 lines):
> # TEXT: testing std::locale globals with 1 thread, 2 iterations each, in
> 16 locales { "C" "POSIX" "AR_DZ.UTF-8" "AR_BH" "AR_AA.UTF-8" "AR_BH.UTF-8"
> "AR_AE.UTF-8" "AR_DZ" "AR_EG.UTF-8" "AR_EG" "AR_AE" "AR_AA" "AR_JO"
> "AR_JO.UTF-8" "AR_KW" "AR_KW.UTF-8" }
> # CLAUSE: lib.locale.global.templates
> # INFO (S1) (3 lines):
> # TEXT: template bool std::has_facet (const locale&)
> # CLAUSE: lib.locale.global.templates
> # INFO (S1) (3 lines):
> # TEXT: template const T& std::use_facet (const locale&)
> # CLAUSE: lib.locale.global.templates
> # WARNING (S5) (3 lines):
> # TEXT: exceptions not thread safe, skipping that part of test
> # CLAUSE: lib.locale.global.templates
> /amd/devco/vitek/stdcxx-trunk/tests/localization/22.locale.globals.mt.cpp:311:
> use_facet_loop: Assertion 'threw || opt_facets [opt_inx_collate] < 0' failed.
> IOT/Abort trap (core dumped)
> [EMAIL PROTECTED] tests]$
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [PATCH] rw_snprintf doesn't null terminate strings
2007-12-18 Travis Vitek <[EMAIL PROTECTED]> * tests/src/printf.cpp (rw_snprintf): Add null terminator to end of copied string to be compatible with sprintf. -- View this message in context: http://www.nabble.com/-PATCH--rw_snprintf-doesn%27t-null-terminate-strings-tp14407607p14407643.html Sent from the stdcxx-dev mailing list archive at Nabble.com.
[PATCH] rw_snprintf doesn't null terminate strings
If rw_snprintf() is intended to behave like sprintf(), it should probably
append the null terminator. If not, I should probably revise my fix to
STDCXX-524 [https://issues.apache.org/jira/browse/STDCXX-524].
Travis
Index: printf.cpp
===
--- printf.cpp (revision 605328)
+++ printf.cpp (working copy)
@@ -3376,8 +3376,10 @@
va_end (va);
-if (size_t (nchars) <= bufsize)
+if (size_t (nchars) < bufsize) {
memcpy (buf, tmpbuf, size_t (nchars));
+buf [nchars] = 0;
+}
free (tmpbuf);
--
View this message in context:
http://www.nabble.com/-PATCH--rw_snprintf-doesn%27t-null-terminate-strings-tp14407607p14407607.html
Sent from the stdcxx-dev mailing list archive at Nabble.com.
[jira] Closed: (STDCXX-676) [MSVC] 22.locale.time.put test fails
[ https://issues.apache.org/jira/browse/STDCXX-676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek closed STDCXX-676. --- Resolution: Fixed > [MSVC] 22.locale.time.put test fails > > > Key: STDCXX-676 > URL: https://issues.apache.org/jira/browse/STDCXX-676 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.2.0 >Reporter: Travis Vitek >Assignee: Travis Vitek > Fix For: 4.2.1 > > Attachments: stdcxx-223.patch > > > In my manual runs I have noticed that the test fails because the MSCRT > strftime doesn't support %T, %e, or %G and asserts internally. This doesn't > appear to happen on all configurations because these tests are running to > completion on some of the nightly builds. > I think the rw_strftime() that is inside the test could be expanded to avoid > the assert inside the CRT so that the test would pass on all windows > configurations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-240) #define _RWSTD_NO_EXCEPTIONS when exceptions are disabled via command line option
[ https://issues.apache.org/jira/browse/STDCXX-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-240: Attachment: stdcxx-240.patch 2007-12-18 Travis Vitek <[EMAIL PROTECTED]> STDCXX-240 * include/rw/_config-acc.h: Conditionally disable exception support if appropriate command line option is set. * include/rw/_config-deccxx.h: Ditto. * include/rw/_config-eccp.h: Ditto. * include/rw/_config-gcc.h: Ditto. * include/rw/_config-icc.h: Ditto. * include/rw/_config-mipspro.h: Ditto. * include/rw/_config-xlc.h: Ditto. I'm filing a new bug on the test suite to get it updated to work when _RWSTD_NO_EXCEPTIONS is defined. > #define _RWSTD_NO_EXCEPTIONS when exceptions are disabled via command line > option > - > > Key: STDCXX-240 > URL: https://issues.apache.org/jira/browse/STDCXX-240 > Project: C++ Standard Library > Issue Type: Improvement > Components: Build >Affects Versions: 4.1.2, 4.1.3, 4.1.4 >Reporter: Martin Sebor >Assignee: Travis Vitek >Priority: Minor > Fix For: 4.2.1 > > Attachments: stdcxx-240.patch > > > Moved from the Rogue Wave bug tracking database: > Class/File: stdcomp.h > Fix Priority: Can Fix > Long Description: > *** Dec 1 1999 6:03PM *** sebor *** > A request for enhancement. > Subject: define RWSTD_NO_EXCEPTIONS when __HPACC_NOEH is > Date: Wed, 01 Dec 1999 17:11:36 -0800 > From: Chichiang Wan <[EMAIL PROTECTED]> > Organization: California Language Labs > To: oemsupport <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED], wanc_at_hp <[EMAIL PROTECTED]> > aCC has an option +noeh. When it is provided, __HPACC_NOEH will be > defined. It would be nice for users to need to only use +noeh. For > that, > RWSTD_NO_EXCEPTIONS needs to be defined conditionally. > = > $ cat test.C > #include > $ aCC +noeh -c test.C > Error 46: "/opt/aCC/include/memory", line 493 # Exception handling is > not > enabled (do not use the +noeh flag to aCC). > RWSTD_THROW_NO_MSG(tmp == 0, bad_alloc); > -- Chichiang > Modified By: sebor @ May 29, 2000 10:28:25 PM > We should do this AND test it -- not just on aCC but in general with all > compilers that support this feature. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-681) Test suite and example programs don't compile on platforms that don't support exceptions
Test suite and example programs don't compile on platforms that don't support exceptions Key: STDCXX-681 URL: https://issues.apache.org/jira/browse/STDCXX-681 Project: C++ Standard Library Issue Type: Bug Components: Tests Affects Versions: 4.2.0 Reporter: Travis Vitek Priority: Minor Many of the test programs don't compile if _RWSTD_NO_EXCEPTIONS is defined. All of our primary and secondary platforms support exceptions by default, but this support can usually be disabled with a command line argument to the compiler. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-240) #define _RWSTD_NO_EXCEPTIONS when exceptions are disabled via command line option
[ https://issues.apache.org/jira/browse/STDCXX-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-240: Attachment: (was: stdcxx-240.patch) > #define _RWSTD_NO_EXCEPTIONS when exceptions are disabled via command line > option > - > > Key: STDCXX-240 > URL: https://issues.apache.org/jira/browse/STDCXX-240 > Project: C++ Standard Library > Issue Type: Improvement > Components: Build >Affects Versions: 4.1.2, 4.1.3, 4.1.4 >Reporter: Martin Sebor >Assignee: Travis Vitek >Priority: Minor > Fix For: 4.2.1 > > > Moved from the Rogue Wave bug tracking database: > Class/File: stdcomp.h > Fix Priority: Can Fix > Long Description: > *** Dec 1 1999 6:03PM *** sebor *** > A request for enhancement. > Subject: define RWSTD_NO_EXCEPTIONS when __HPACC_NOEH is > Date: Wed, 01 Dec 1999 17:11:36 -0800 > From: Chichiang Wan <[EMAIL PROTECTED]> > Organization: California Language Labs > To: oemsupport <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED], wanc_at_hp <[EMAIL PROTECTED]> > aCC has an option +noeh. When it is provided, __HPACC_NOEH will be > defined. It would be nice for users to need to only use +noeh. For > that, > RWSTD_NO_EXCEPTIONS needs to be defined conditionally. > = > $ cat test.C > #include > $ aCC +noeh -c test.C > Error 46: "/opt/aCC/include/memory", line 493 # Exception handling is > not > enabled (do not use the +noeh flag to aCC). > RWSTD_THROW_NO_MSG(tmp == 0, bad_alloc); > -- Chichiang > Modified By: sebor @ May 29, 2000 10:28:25 PM > We should do this AND test it -- not just on aCC but in general with all > compilers that support this feature. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-524) buffer overflow in test 22.locale.time.get.cpp (make_LC_TIME)
[ https://issues.apache.org/jira/browse/STDCXX-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-524: Severity: Runtime Error Summary: buffer overflow in test 22.locale.time.get.cpp (make_LC_TIME) (was: buffer overflow in test 22.locale.time.get.cpp(make_LC_TIME)) Added a missing space. > buffer overflow in test 22.locale.time.get.cpp (make_LC_TIME) > - > > Key: STDCXX-524 > URL: https://issues.apache.org/jira/browse/STDCXX-524 > Project: C++ Standard Library > Issue Type: Bug > Components: Tests >Affects Versions: 4.1.2, 4.1.3, 4.1.4 >Reporter: Travis Vitek >Assignee: Travis Vitek >Priority: Trivial > Fix For: 4.2.1 > > Attachments: stdcxx-524.patch > > > This test uses L_tmpnam to determine the length of a buffer used to store a > filename string. Unfortunately, L_tmpnam is intended for use with tmpnam(), > but the buffer is written to with std::sprintf(). When I run the test, the > allocated buffer is 46 bytes, and the sprintf() call writes 58 bytes [this > will vary based on user name and other variables]. Perhaps the buffer should > be made larger, or some other method should be used to fill the buffer. > Perhaps this would work. > #if !defined (_WIN32) && !defined (_WIN64) > # define _PATH_MAX PATH_MAX > #else > # define _PATH_MAX _MAX_PATH > #endif > char srcfname [_PATH_MAX]; // [L_tmpnam + 32]; > std::sprintf (srcfname, "%s" SLASH "LC_TIME.src", locale_root); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-459) time_get::date_order() should return actually date order taken from locale
[ https://issues.apache.org/jira/browse/STDCXX-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-459: - Fix Version/s: (was: 4.2.1) 4.3 Scheduled for 4.3. > 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, 4.1.3, 4.1.4 > Environment: All >Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.3 > > Attachments: stdcxx-459.patch > > > 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] Commented: (STDCXX-459) time_get::date_order() should return actually date order taken from locale
[ https://issues.apache.org/jira/browse/STDCXX-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552871 ] Farid Zaripov commented on STDCXX-459: -- 1. This change is not necessary (and even more, it's incorrect, because __rw_get_timepunct() should be exported if the user instantiates the std::time_get). 2. The __rw_get_dateorder() should also be _RWSTD_EXPORT to be accessible from std::time_get. And this change is not a forward binary compatible. 3. I think yes. The outlining doesn't add's the new symbol in the library. The only what may change - it's a return value from the date_order(). But since the all possible returning values are valid (the user of the library shouldn't rely on the always returned no_order from date_order()) this change is safe. > 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, 4.1.3, 4.1.4 > Environment: All >Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Minor > Fix For: 4.2.1 > > Attachments: stdcxx-459.patch > > > 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] Commented: (STDCXX-675) [MSVC] implement autolinking feature
[ https://issues.apache.org/jira/browse/STDCXX-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552841 ] Farid Zaripov commented on STDCXX-675: -- Yes. This change doesn't affect the exported symbols or anything else. It's only add's the record in object files, compiled with using this change, to link these object files with libstdxx.lib. > [MSVC] implement autolinking feature > > > Key: STDCXX-675 > URL: https://issues.apache.org/jira/browse/STDCXX-675 > Project: C++ Standard Library > Issue Type: Improvement > Components: Configuration >Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 > Environment: MSVC, ICC/Windows >Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Trivial > Fix For: 4.2.1 > > Attachments: autolink.patch > > > At the moment the users of the library should explicitly specify the used > library name in linker command line. Here might be problems if the user's > project was compiled with config.h for some configuration (let's say 12d) but > linked with library for another configuration (i.e. libstd12s.lib). > The MSVC and ICC/Windows has the posibility to specify the library using > #pragma comment (lib, libname) directive. So #including any header from the > library will leads to linking automatically with the proper library file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
