Eric Lemings wrote:
-Original Message-
From: Eric Lemings [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 24, 2008 10:49 AM
To: dev@stdcxx.apache.org
Subject: RE: stdcxx move to TLP complete
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent
William A. Rowe, Jr. wrote:
Tim Adams wrote:
Our experience with our customer base indicates that MSVC 7.0 was
abandoned quickly in favor of 7.1.
FWIW - that same generation, VS.NET's C++.NET implementation model
was completely abandoned and restructured in VS.2005 (a massively
better
The issue should be linked as a duplicate of STDCXX-614 and
on closing the Status set to Duplicate. We might also need
to edit the time tracking info so we don't throw off our
reporting (I don't know if it would).
Martin
Eric Lemings (JIRA) wrote:
[
Farid Zaripov wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Monday, January 28, 2008 10:26 PM
To: dev@stdcxx.apache.org
Subject: Re: svn commit: r616003 -
/stdcxx/branches/4.2.x/tests/utilities/20.temp.buffer.cpp
Should we do this in rw_new.h
Scott Zhong wrote:
Could
addr = (char*)(void*)size_t(-1);
Be a better choice for a bad address?
I'm not sure.
The weird looking expression in the function tries to compute
an address that's beyond the last text segment page, or 16MB
past the address of the bad_address function. It was
Travis Vitek wrote:
[...]
FYI, the setlocale() names can be really long on some platforms (e.g.,
on HP-UX, they always take the form:
/category/category/category/category/category/category
so 64 characters may not be enough for all locales).
I thought this was only the case when using
[EMAIL PROTECTED] wrote:
Author: vitek
Revision: 617300
Modified property: svn:log
Modified: svn:log at Thu Jan 31 16:05:43 2008
--
--- svn:log (original)
+++ svn:log Thu Jan 31 16:05:43 2008
@@ -2,5 +2,5 @@
2008-01-31
FYI: A couple of time tracking reports might be of interest:
Version Workload Report: http://tinyurl.com/2wpdgj
Time Tracking Report: http://tinyurl.com/3xtq6b
PROTECTED]
Not yet. I was hoping to get to it this week but lately time has
a habit of getting away from me... You don't happen to know where
to change this, do you?
Martin
Gav...
quote who=Martin Sebor (JIRA)
[
https://issues.apache.org/jira/browse/STDCXX-686?page
William A. Rowe, Jr. wrote:
Martin Sebor wrote:
After Feature Freeze, our release process says that only the RM
does merges. Unless the RM wants to merge each change individually
the multi-change format is the only one that makes sense.
Just want to point out or clarify a few things
Farid Zaripov wrote:
I still unable to subscribe to the issues@ list.
I've sent the empty message to the issues-subscribe@, but
nothing happend. Then I've sent the same message to the
issues-help@ and received the reply from ezmlm with the
help message.
Then I've tried to get the
Scott Zhong wrote:
Hi All,
I had finally found the source of the link warnings: it is occurring
because in the linker we use relative path in the library lookup -L
relative path which confuses the linker as to which stdcxx library to
use. This is because the compiler comes with a version of
Travis Vitek (JIRA) wrote:
[
https://issues.apache.org/jira/browse/STDCXX-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Travis Vitek updated STDCXX-449:
Description:
Running the Intel Thread Checker on the string thread
Travis Vitek wrote:
Martin,
Thank you for the additional testcases. They point out a few issues that I
didn't interpret from the description in the Bash Reference Manual
[http://www.gnu.org/software/bash/manual/bashref.html#Brace-Expansion]. Note
that below I refer to paragraphs from this
Travis Vitek wrote:
Travis Vitek wrote:
Travis Vitek wrote:
Martin Sebor wrote:
I don't have the time to do a careful review of the patch WRT
the LWG issue at the moment but I note there's a comment above
the code that's being modified that references the issue, so
it looks like
So, in conclusion, I think the way to proceed is to open a new
ticket for the inconsistency between LWG issue 231 and punct.cpp
and treat it separately from STDCXX-2. FWIW, I was about to add
it but Jira appears to be down at the moment...
Martin
Farid Zaripov wrote:
The
Eric Lemings wrote:
FWIW, I was just reading the description for Jira issue STDCXX-536 and
the associated comments.
I believe this is basically what Travis has already stated in a round-
about manner but it seems to me that if a test is timing out, there are
two possibilities: 1. the test is
I don't think it's that simple. IIRC, the problem is that we're using
mbsrtowcs() on sequences that aren't guaranteed to be NUL-terminated.
It seems that it should be straightforward to either specify a limit
to mbsrtowcs() that's small enough so as to prevent the function from
ever reaching the
Eric Lemings wrote:
[...]
Right. And I believe that limit is
min(__from_end-__from, __to_limit-__to)
Suppose MB_CUR_MAX=4, the size of the source sequence is 1 byte
(with no terminating NUL), and the byte doesn't form a complete
multibyte character. There's no way to tell the
Travis Vitek wrote:
From: Apache Wiki [mailto:[EMAIL PROTECTED]
The new
interface will need to make it easy to specify such a set of
locales without explicitly naming them, and it will need to
retrieve such locales without returning duplicates.
As mentioned before I don't know a good
Travis Vitek wrote:
[...]
I think it might be simpler to keep things abstract but given my
specification above a simple query string would look like this:
en_US.*1\n
zh_*.UTF-8 2\n
zh_*.UTF-8 3\n
zh_*.UTF-8 4\n
for the equivalent of:
locale == en_US.* MB_CUR_MAX == 1
Scott, if you expect to be creating a bunch of these please try to
remember to prepend the platform string to the tile of each subtask
the same way STDCXX-729 does. Our filters key in on it when looking
for platform-specific issues.
Alternatively, if it looks like there might be too many
Eric Lemings wrote:
I just tried building on an HP-IPF machine and encountered a failure
while building the tests. See attached file.
ezmlm strips attachments unless it's been told not to. Outlook is
usually the email client that tends to cause this even with plain
text files because it's
Eric Lemings wrote:
FYI. I'm also seeing this build failure on HP-UX as well:
I don't see this error on the head of trunk either with gcc 4.1.1
on Solaris or 4.1.2 on Linux. If you see the same problem on trunk
please open an issue for it mentioning the gcc version and build
type.
Martin
[EMAIL PROTECTED] wrote:
Author: faridz
Date: Sat Mar 15 21:48:29 2008
New Revision: 637539
URL: http://svn.apache.org/viewvc?rev=637539view=rev
Log:
2008-03-16 Farid Zaripov [EMAIL PROTECTED]
STDCXX-635
* include/deque (operator-): If one of the iterators is the iterator
$MPFR_TESTS_TIMEOUT overrides NUM (0: no
timeout).
Right. I thought we could do something similar.
Martin
Brad.
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Sunday, March 09, 2008 5:41 PM
To: dev@stdcxx.apache.org
Subject: Re
[EMAIL PROTECTED] wrote:
Author: faridz
Date: Tue Mar 18 07:22:15 2008
New Revision: 638382
Just out of curiosity: are these warnings new in MSVC 9? (I don't
think they show up in MSVC 8 builds.)
Martin
URL: http://svn.apache.org/viewvc?rev=638382view=rev
Log:
2008-03-18 Farid Zaripov
Farid Zaripov wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Tuesday, March 18, 2008 5:31 PM
To: dev@stdcxx.apache.org
Subject: Re: svn commit: r638382 - in /stdcxx/trunk:
include/fstream include/istream src/podarray.h
[EMAIL
[EMAIL PROTECTED] wrote:
Author: faridz
Date: Tue Mar 18 07:09:17 2008
New Revision: 638369
[...]
Modified: stdcxx/trunk/include/loc/_num_get.h
URL:
http://svn.apache.org/viewvc/stdcxx/trunk/include/loc/_num_get.h?rev=638369r1=638368r2=638369view=diff
Farid Zaripov wrote:
Why if _PA_RISC2_0 macro is defined the atimic functions are named
__rw_string_atomic_xxx() but no __rw_atomic_xxx() as on other platforms?
I'm not sure but I wonder if the PA atomic functions aren't
the ones that reserve a specific value as the lock value.
I.e., they're
Travis Vitek wrote:
Eric Lemings wrote:
Greetings,
I've been stepping through one of the string tests. The
std::string::at() member function is being called with a __pos value
that is = size() causing the _RWSTD_REQUIRES assertion to fail. It
seems to be throwing an exception, which is
This will silence the warnings but I think we might be able to do
better than simply returning from the function. It seems to me,
based on the LC_TIME Locale Definition in POSIX (see below) that
when strtok() returns 0 in the cases below it indicates invalid
input. I think we should diagnose it
I was going to say this is the same bug as STDCXX-764:
http://issues.apache.org/jira/browse/STDCXX-764
but after looking at it more closely I believe the compiler
is correct in this case because malloc() returns 0 when it
fails to allocate memory. The warning could be clearer about
it.
Martin
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Thursday, March 20, 2008 12:02 PM
To: dev@stdcxx.apache.org
Subject: Re: [TESTCASE] STDCXX-750 [HP aCC 6.16] Potential null
pointer
dereference in aliases.cpp
I was going to say
Travis Vitek wrote:
Martin Sebor wrote:
Travis Vitek wrote:
Martin Sebor wrote:
I suspect the SEGV discussed in the thread below is due to the patch
for STDCXX-216: http://svn.apache.org/viewcvs?view=revrev=616673
Reverting the patch makes the error go away. Travis, can you look
=12580978#action_12580978
Martin Sebor wrote:
Travis Vitek wrote:
Martin Sebor wrote:
Travis Vitek wrote:
Martin Sebor wrote:
I suspect the SEGV discussed in the thread below is due to the patch
for STDCXX-216: http://svn.apache.org/viewcvs?view=revrev=616673
Reverting the patch makes the error
Eric Lemings wrote:
I haven't looked to confirm this but it looks like the Makefile(s)
ignore errors building the test programs but the build process still
stops (i.e. exits successfully). I was wondering if the Makefile(s)
shouldn't also continue building the remaining test programs (i.e.
Sorry Scott, I'm still not sure this is completely correct.
According to 7.18.1.1 of C99, The typedef name intN_t designates
a signed integer type with width N, no padding bits, and a two's
complement representation.
Can you point me to the part of the patch that checks that each
of the
Travis Vitek wrote:
Martin Sebor wrote:
But we do need to come up with a sound specification of the query syntax
before implementing any more code.
Okay, the proposed query syntax grammar essentially the same as that being
used for the config value in xfail.txt. So we have
match
Farid Zaripov wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 19, 2008 6:46 PM
To: dev@stdcxx.apache.org
Subject: Re: svn commit: r638369 - in /stdcxx/trunk/include:
loc/_num_get.cc loc/_num_get.h rw/_iosfwd.h
URL: http://svn.apache.org
FYI: I've created a set of cross-platform build result pages for
4.2.0 to help us detect regressions in 4.2.1:
http://people.apache.org/~sebor/stdcxx-4.2.0/results/builds/
There is at least one glitch that I know of that still needs to
be worked out: the links to files in Subversion point to
-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of
Martin Sebor
Sent: Friday, March 21, 2008 5:10 PM
To: dev@stdcxx.apache.org
Subject: Re: [STDCXX-709] ContainerData ctor and
UserClass::from_char()
Eric Lemings wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL
when porting to new versions of
compilers or compilers on new platforms.
Martin
Martin Sebor wrote:
The two versions of aCC are very different (based on a different
C++ front ends). Each also runs on a different OS and hardware.
I think significant differences are to be expected. That doesn't
Eric Lemings wrote:
Here's an error compiling the NEW_OFLOW_SAFE.cpp config test:
aCC -mt -I. -AA +w +W392 +W655 +W684 +W818 +W819 +W849 +W2193 +W2236
+W2261 +W2340 +W240
1 +W2487 +W4227 +W4229 +W4231 +W4235 +W4237 +W4249 +W4255 +W4272 +W4284
+W4285 +W4286 +W42
96 +W4297 +W3348 -c
Farid Zaripov wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Tuesday, March 25, 2008 3:46 AM
To: dev@stdcxx.apache.org
Subject: Re: NEW_OFLOW_SAFE config test
Eric Lemings wrote:
Here's an error compiling the NEW_OFLOW_SAFE.cpp
Eric Lemings wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Monday, March 24, 2008 3:41 PM
To: dev@stdcxx.apache.org
Subject: Re: [STDCXX-709] ContainerData ctor and
UserClass::from_char()
...
try to create a small test case
) (4 lines):
# TEXT: /amd/devco/sebor/stdcxx/tests/src/new.cpp:211: operator delete[]
(0x400d1c7c): invalid pointer
# CLAUSE: lib.list.assign
# LINE: 209
Martin Sebor wrote:
Eric Lemings wrote:
[...]
I also created a little test case in trunk/tests/containers that
links to the rwtest static
Farid Zaripov wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Tuesday, March 25, 2008 5:11 PM
To: dev@stdcxx.apache.org
Subject: Re: svn commit: r640831 - /stdcxx/trunk/include/sstream.cc
Any idea what caused it? I've gone through
Travis Vitek wrote:
sebor-2 wrote:
Author: sebor
Date: Sat Mar 22 16:45:59 2008
New Revision: 640122
URL: http://svn.apache.org/viewvc?rev=640122view=rev
Log:
2008-03-22 Martin Sebor [EMAIL PROTECTED]
STDCXX-768
* include/ansi/climits: Used gcc's #include_next to include
4.2.1 issues that have been resolved on trunk but whose fixes
have not been merged to 4.2.x will need to be merged at some
point in the near future. The way I have been expecting this
to happen is have someone (e.g., the Release Manager) go
through all 4.2.1 issues in Resolved (but not Closed)
Eric Lemings wrote:
-Original Message-
From: Eric Lemings [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2008 10:55 AM
To: dev@stdcxx.apache.org
Subject: RE: [STDCXX-709] ContainerData ctor and
UserClass::from_char()
...
I think you're right. I set a breakpoint in
Unless someone has a burning desire to fill that role this
time around I volunteer to take on this responsibility for
the upcoming 4.2.1 release. Let me know your thoughts,
suggestions, or objections. If there are none I'll start
a vote.
Martin
, using VisualAge 6 as a precedent MSVC 7.1 should
remain a Secondary Platform until 4.3.
Martin
-- Tim
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Thursday, March 20, 2008 10:08 AM
To: dev@stdcxx.apache.org
Subject: 4.2.1 platforms
Apache Wiki wrote:
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Stdcxx Wiki for change
notification.
The following page has been changed by TravisVitek:
http://wiki.apache.org/stdcxx/LocaleLookup
[EMAIL PROTECTED] wrote:
Author: faridz
Date: Thu Mar 27 04:05:41 2008
New Revision: 641783
URL: http://svn.apache.org/viewvc?rev=641783view=rev
Log:
2008-03-27 Farid Zaripov [EMAIL PROTECTED]
* tests/src/braceexp.cpp (_rw_string_buffer): Declare n parameter as
_RWSTD_SIZE_T
Eric Lemings wrote:
You like whipping up scripts a lot so I was wonderin: do you have a
script suitable as a cron job that determines if the Apache Subversion
repository is available and if so proceeds to grab a snapshot, build it,
and email the results?
I was thinking about writing such a
Travis Vitek wrote:
Martin Sebor wrote:
Here are some observations and suggestions regarding the patch:
# Underscores separating components of file names should be replaced with
dashes for consistency with the {{rw/_config-*.h}} headers.
# There's a typo in the name of {{_atomic_aplha.h
Scott Zhong wrote:
http://issues.apache.org/jira/browse/STDCXX-401
Title: test suite should honor TMPDIR
stdcxx-401 patch part 1 is in
http://mail-archives.apache.org/mod_mbox/stdcxx-dev/200803.mbox/%3cCFFDD
[EMAIL PROTECTED]
stdcxx-401 patch part 2 affects:
./src/file.cpp
Travis Vitek wrote:
Travis Vitek wrote:
Martin Sebor wrote:
Travis Vitek wrote:
+ || 22.LOCALE.CONS.MT.CPP || *1,+ ||
+ || 22.LOCALE.CTYPE.CPP || *2 ||
+ || 22.LOCALE.CTYPE.IS.CPP || *2 ||
+ || 22.LOCALE.CTYPE.MT.CPP || *1,+ ||
+ || 22.LOCALE.CTYPE.NARROW.CPP || *2 ||
+ || 22
The regression tests below are all failing with SIGABRT.
I check the issues and they have all been deferred, so
what's missing is an entry for each of these tests in
xfail.txt to mark them up on our build result pages.
21.string.assign.stdcxx-629
21.string.insert.stdcxx-630
The 23.deque.iterators test is failing with a SIGABRT.
Reverting the most recent changes to deque made to fix
STDCXX-635 lets the test pass. Farid, can you please
look into it?
http://svn.apache.org/viewvc?view=revrevision=637539
Thanks
Martin
$ ./23.deque.iterators
# INFO (S1) (10 lines):
#
[EMAIL PROTECTED] wrote:
Author: vitek
Date: Fri Mar 28 14:28:41 2008
New Revision: 642397
URL: http://svn.apache.org/viewvc?rev=642397view=rev
Log:
2008-03-28 Travis Vitek [EMAIL PROTECTED]
STDCXX-714
* tests/src/braceexp.cpp: Remove _rw_isspace(), _rw_isupper() and
[EMAIL PROTECTED] wrote:
Author: vitek
Date: Fri Mar 28 14:28:41 2008
New Revision: 642397
URL: http://svn.apache.org/viewvc?rev=642397view=rev
Log:
2008-03-28 Travis Vitek [EMAIL PROTECTED]
STDCXX-714
* tests/src/braceexp.cpp: Remove _rw_isspace(), _rw_isupper() and
FYI: I went ahead and fixed this to minimize the number of lost
build results over the rest of the weekend. Hope my changes are
okay with you: http://svn.apache.org/viewvc?rev=642646view=rev
Martin
Martin Sebor wrote:
[EMAIL PROTECTED] wrote:
Author: vitek
Date: Fri Mar 28 14:28:41 2008
New
In the shell, spaces that are otherwise treated as separators can
be either escaped or quoted to have them interpreted as ordinary
characters. The rw_xxx_expand() functions let me escape spaces but
they don't seem to like quoting. For example, the shell expands
the following three strings to the
Eric Lemings wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Thursday, March 27, 2008 2:50 PM
To: dev@stdcxx.apache.org
Subject: Re: [jira] Commented: (STDCXX-563) split up rw/_mutex.h
...
Right. IMO, we should go
Eric Lemings wrote:
-Original Message-
From: Eric Lemings
Sent: Thursday, March 27, 2008 2:05 PM
To: 'dev@stdcxx.apache.org'
Subject: RE: [STDCXX-709] ContainerData ctor and
UserClass::from_char()
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent
2007]
Reporter: Scott (Yu) Zhong
Assignee: Martin Sebor
Fix For: 4.2.1
Original Estimate: 2h
Remaining Estimate: 2h
aCC -c-mt -I/amd/devco/scottz/stdcxx/4.2.x/include
-I/build/scottz/12d/include -AA +O2 +DD64 +w +W392 +W655 +W684 +W818 +W819
+W849 +W2193
Eric Lemings wrote:
file stdcxx/trunk/etc/config/src/FLOAT.cpp:
228 #ifndef _RWSTD_NO_LONG_DOUBLE
229 # if defined (LDBL_EPSILON)
230 PRINTFLT (LDBL_EPSILON, LDBL_FMT, LDBL_DIG, L);
231 # endif // LDBL_EPSILON
LDBL_DIG? Cut'n'paste error?
I don't see anything wrong here. The third
[EMAIL PROTECTED] wrote:
Author: ablack
Date: Tue Apr 1 08:36:22 2008
New Revision: 643448
URL: http://svn.apache.org/viewvc?rev=643448view=rev
Log:
2008-04-01 Andrew Black [EMAIL PROTECTED]
* etc/config/windows/run_locale_utils.wsf (run_locale_utils):
Replication of r643435
Scott Zhong wrote:
In the debug build of aCC 6.05 for stdcxx trunk, there are too many
warnings that made the build log file to be larger than what the nightly
build infrastructure could handle. This is causing debug builds to show
up as DATA in the results page.
Thanks for the heads up. Is
[EMAIL PROTECTED] wrote:
Author: elemings
Date: Tue Apr 1 09:40:44 2008
New Revision: 643473
URL: http://svn.apache.org/viewvc?rev=643473view=rev
Brad, a few notes on the format of your Change Log. Our
convention is to use the GNU/Emacs format for Change Logs
described in the Emacs manual:
Eric Lemings wrote:
[...]
STDCXX-708 https://issues.apache.org/jira/browse/STDCXX-708
Each line should be indented by a single TAB. The issue URL
shouldn't be here.
Why not?
Because we don't put it there. There's a documented convention
that we follow (see below). It says nothing about
Martin Sebor wrote:
Travis Vitek wrote:
Martin Sebor wrote:
[...]
I think we need to decide if trunk is supposed to be a copy of
4.2.x or if it's for development of future versions. If the
latter, there's no problem with keeping tests like it there
as long as they're passing or as long
Eric Lemings wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Tuesday, April 01, 2008 4:11 PM
To: dev@stdcxx.apache.org
Subject: on branches and merging (was: Re: failing regression tests)
...
It occurs to me that even if most
PING? Should I open an issue for this or is it something you're
already working on or planning to?
Martin Sebor wrote:
In the shell, spaces that are otherwise treated as separators can
be either escaped or quoted to have them interpreted as ordinary
characters. The rw_xxx_expand
Environment: all
Reporter: Martin Sebor
Assignee: Farid Zaripov
Priority: Minor
Attachments: num_put.diff
The output of the program below is different depending on the operating system
it runs on. It should be the same (preferably like that on AIX
Andrew, we're getting a bunch of new signed/unsigned comparison
warnings after this change. Can you look into silencing them when
you have a minute?
$TOPDIR/util/output.cpp: In function ‘bool rbinit(readback*, FILE*)’:
$TOPDIR/util/output.cpp:88: warning: comparison between signed and
unsigned
Farid Zaripov wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Wednesday, April 02, 2008 7:54 PM
To: dev@stdcxx.apache.org
Subject: Re: svn commit: r643964 - /stdcxx/trunk/include/rw/_traits.h
Thanks for looking into this for me
Travis Vitek wrote:
Martin Sebor wrote:
Travis Vitek wrote:
Travis Vitek commented on STDCXX-742:
-
This is happening because we don't use the -qrtti=dynamiccast
option. We internally use a dynamic_cast to determine if the
facet is of the correct
Travis Vitek wrote:
Martin Sebor wrote:
Great, that fixes locale.cpp. Thanks for doing that. I was also
(or mainly) pointing out the same problems in braceexp.cpp. I
hesitate to commit a fix myself in case you're working on the
file but here's a patch that addresses the remaining problems
Travis Vitek wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 03, 2008 8:55 AM
To: dev@stdcxx.apache.org
Subject: Re: svn commit: r644364 - in /stdcxx/trunk:
src/locale_global.cpp tests/localization/22.locale.statics.mt.cpp
[EMAIL
Travis Vitek wrote:
Martin Sebor wrote:
Travis Vitek wrote:
Right. It seems that for this to be mt-safe with respect to other
library code that calls setlocale(), we would need to lock the
same lock that is used by _RW::__rw_setlocale. If don't use the
same lock it would be possible
William A. Rowe, Jr. wrote:
William A. Rowe, Jr. wrote:
who wants to introduce what's up and coming in stdcxx 4.3/5.0, from
a C++ developer perspective?
I was hoping to make it and give a presentation but we couldn't
work out a good schedule. I'm tentatively planning on giving one
at New
Here's the process I use for reference. Let me know if you have
suggestions for improvements, otherwise I'd like to put it up
on the Wiki as the recommended process to follow.
1. using the cross-build result pages currently at
http://people.apache.org/~sebor/stdcxx/results/builds/
Project: C++ Standard Library
Issue Type: Bug
Components: Tests
Affects Versions: 4.2.0
Environment: Sun C++ 5.9/Solaris/AMD64
Reporter: Martin Sebor
Assignee: Eric Lemings
Fix For: 4.2.1
Original Estimate: 4h
Remaining
what conditions should failures in
newly added tests should be considered a regression. Let's discuss.
Martin Sebor wrote:
Here's the process I use for reference. Let me know if you have
suggestions for improvements, otherwise I'd like to put it up
on the Wiki as the recommended process to follow
[EMAIL PROTECTED] wrote:
Author: faridz
Date: Wed Apr 9 12:25:47 2008
New Revision: 646489
URL: http://svn.apache.org/viewvc?rev=646489view=rev
Log:
2008-04-09 Farid Zaripov [EMAIL PROTECTED]
* tests/localization/22.locale.time.put.cpp (set_TZ): New function to
set TZ
Farid Zaripov wrote:
Below is a listing of the raise() function from MSVC CRT:
abort() has the same effect as exit(3) on Windows? What a mess!
Maybe we should ditch abort() and use TerminateProcess() instead,
with some unique value to let us distinguish our own SIGABRT from
exit(3).
Martin
(the latest patch installed on marbles is 121018-13
from 2008/01/02). But they both exhibit the same problem.
The stack trace from the 15S build is attached.
Martin
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Wednesday, April 09, 2008
Scott Zhong wrote:
Martin, do I need to switch to the new tags to do nightly testing?
No, we already have a full set of results for the tag and it will
never change (it's a read-only snapshot).
Martin
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf
Eric Lemings wrote:
Is it safe to pass a null pointer as the 2nd argument to memcpy()? Or
undefined?
Assuming the third argument is 0. Strictly speaking I believe it's
undefined because memcpy(s1, s2, n) is specified to copy n bytes
from the object pointed to by s2 into the object pointed
number of arguments, the behavior is undefined. ...
Here's an answer to the same question on comp.lang.c.moderated:
http://tinyurl.com/6eqo3n
Martin Sebor wrote:
Eric Lemings wrote:
Is it safe to pass a null pointer as the 2nd argument to memcpy()? Or
undefined?
Assuming the third argument
Check out: http://stdcxx.markmail.org/
Very cool!
Farid Zaripov wrote:
In library headers somewhere used _RWSTD_NO_BOOL and somewhere -
_RWSTD_NO_NATIVE_BOOL.
The _RWSTD_NO_BOOL.is determined at configure step, but _RWSTD_NO_NATIVE_BOOL -
not. At the same time
_RWSTD_NO_NATIVE_BOOL mentioned in readme file, while _RWSTD_NO_BOOL - doesn't.
Travis Vitek wrote:
Martin Sebor wrote:
[EMAIL PROTECTED] wrote:
URL: http://svn.apache.org/viewvc?rev=647908view=rev
Log:
2008-04-14 Travis Vitek [EMAIL PROTECTED]
STDCXX-857
* tests/src/fmt_defs.h: Add flag to struct Buffer to indicate
who owns the allocated
[EMAIL PROTECTED] wrote:
Author: faridz
Date: Mon Apr 14 01:38:10 2008
New Revision: 647698
URL: http://svn.apache.org/viewvc?rev=647698view=rev
Log:
2008-04-14 Farid Zaripov [EMAIL PROTECTED]
STDXX-854
* include/loc/_ctype.h (narrow): Don't cast __c to unsigned char,
Eric Lemings wrote:
Is there an macro function (or similar macro function) that calls the
rw_assert() function automatically passing it the __FILE__ and __LINE__
arguments?
Unfortunately, there isn't. No. rw_assert() is a variable
argument function and since C99 varargs macros haven't been
Travis Vitek wrote:
Martin Sebor wrote:
Eric Lemings wrote:
Is there an macro function (or similar macro function) that calls the
rw_assert() function automatically passing it the __FILE__
and __LINE__ arguments?
Unfortunately, there isn't. No. rw_assert() is a variable
argument function
I'm getting ready to merge a few last minute changes from last
week to 4.2.x. I can't tell from the description of this change
if this fix is important for 4.2.1 or not. Farid?
[EMAIL PROTECTED] wrote:
Author: faridz
Date: Fri Apr 18 11:35:41 2008
New Revision: 649647
URL:
1 - 100 of 408 matches
Mail list logo
