Re: low hanging fruit while cleaning up test failures

Travis Vitek wrote: Martin Sebor wrote: I added a new function, rw_fnmatch(), to the test driver. It behaves just like the POSIX fnmatch() (the FNM_XXX constants aren't implemented yet). While the main purpose behind the new function is to support STDCXX-683 it should make it easier to also

stdcxx wiki

I think it would be useful to have a wiki. The ASF seems to have two different installations: one is powered by a Confluence Java engine and the other is a python implementation by MoinMoin. Confluence: http://cwiki.apache.org/CWIKI/ MoinMoin:http://wiki.apache.org Does anyone have any

Re: [PATCH] _mutex.h

Farid Zaripov wrote: The one of the problems in boost regression tests on MSVC 7.1 was caused by #definition _InterlockedIncrement as InterlockedIncrement. The patch below fixes the problem. The MSVC 7.1 also has the intrinsic interlocked functions, but the are not declared in any header

Re: stdcxx wiki

Martin Sebor wrote: Does anyone have any experience with either engine that might be helpful in deciding between the two? Or preference for one over the other? All the projects I participate in use the MoinMoin wiki, and are essentially happy with it. Bill

Re: low hanging fruit while cleaning up test failures

Martin Sebor wrote: Travis Vitek wrote: Martin Sebor wrote: I added a new function, rw_fnmatch(), to the test driver. It behaves just like the POSIX fnmatch() (the FNM_XXX constants aren't implemented yet). While the main purpose behind the new function is to support STDCXX-683 it

Re: low hanging fruit while cleaning up test failures

Travis Vitek wrote: Martin Sebor wrote: Travis Vitek wrote: Martin Sebor wrote: I added a new function, rw_fnmatch(), to the test driver. It behaves just like the POSIX fnmatch() (the FNM_XXX constants aren't implemented yet). While the main purpose behind the new function is to support

Re: low hanging fruit while cleaning up test failures

Martin Sebor wrote: Travis Vitek wrote: Martin Sebor wrote: Travis Vitek wrote: Martin Sebor wrote: I added a new function, rw_fnmatch(), to the test driver. It behaves just like the POSIX fnmatch() (the FNM_XXX constants aren't implemented yet). While the main purpose behind the

[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 ] Martin Sebor updated STDCXX-605: Attachment: stdcxx-605-v3.patch What do you think about the modification in the attached patch?

[jira] Updated: (STDCXX-620) purify reports memory leak in 21_nonmembers test

[ https://issues.apache.org/jira/browse/STDCXX-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-620: Patch Info: (was: [Patch Available]) I don't see a patch anywhere... purify reports memory

[jira] Commented: (STDCXX-597) purify reports uninitialized memory read in _rw_get_char

[ https://issues.apache.org/jira/browse/STDCXX-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12555420#action_12555420 ] Martin Sebor commented on STDCXX-597: - Travis, I get one assertion from 0.char before

[jira] Updated: (STDCXX-577) purify reports leaked memory in stocks example

[ https://issues.apache.org/jira/browse/STDCXX-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-577: Attachment: stocks-valgrind.log Btw., I get the attached leaks from valgrind on Linux (11S) even

Re: low hanging fruit while cleaning up test failures

Travis Vitek wrote: Martin Sebor wrote: Travis Vitek wrote: Martin Sebor wrote: Travis Vitek wrote: Martin Sebor wrote: I added a new function, rw_fnmatch(), to the test driver. It behaves just like the POSIX fnmatch() (the FNM_XXX constants aren't implemented yet). While the main

Re: prototype of the expected failures enhancement (STDCXX-683)

Martin, Most of the links to the log files are broken. They all point to files in http://people.apache.org/tmp/. Also, I'm not sure I understand how rows in the tables are supposed to be arranged now. If I recall, they used to be ordered alphabetically but after your change 26 comes before 23,

Re: prototype of the expected failures enhancement (STDCXX-683)

Mark Brown wrote: Martin, Most of the links to the log files are broken. I see it, thanks. I'm working on a patch. They all point to files in http://people.apache.org/tmp/. Also, I'm not sure I understand how rows in the tables are supposed to be arranged now. If I recall, they used to be

[jira] Created: (STDCXX-685) [Windows] slashes in Windows pathnames in build logs

[Windows] slashes in Windows pathnames in build logs Key: STDCXX-685 URL: https://issues.apache.org/jira/browse/STDCXX-685 Project: C++ Standard Library Issue Type: Bug

Re: low hanging fruit while cleaning up test failures

[forwarding back to the list] Travis Vitek wrote: Martin, Not all supported platforms have the GB18030 encoding [HP, Compaq and IRIX don't], and of those that do, they use different names [gb18030 vs GB18030]. Same with UTF-8 [utf8, UTF8 or UTF-8]. I realize that. That's the reason why I

Re: low hanging fruit while cleaning up test failures

Martin Sebor wrote: [forwarding back to the list] Travis Vitek wrote: Martin, Not all supported platforms have the GB18030 encoding [HP, Compaq and IRIX don't], and of those that do, they use different names [gb18030 vs GB18030]. Same with UTF-8 [utf8, UTF8 or UTF-8]. I realize that.