Re: PR 13631 Problems in messages

2015-03-18 Thread Jonathan Wakely
On 03/12/14 14:54 +, Jonathan Wakely wrote: On 02/12/14 23:58 +0100, François Dumont wrote: DR libstdc++/13631 s/DR/PR/ * include/bits/codecvt.h (codecvtchar, char, mbstate_t): friend class std::messageschar. (codecvtwchar_t, char, mbstate_t): friend class

Re: PR 13631 Problems in messages

2015-03-18 Thread Jonathan Wakely
On 18/03/15 16:17 +, Jonathan Wakely wrote: The new get_glibc_msg function doesn't compile with old versions of glibc, _M_name_messages is not defined (the code is also not exception safe, but that was not introduced by the recent changes). We can probably drop that old code completely,

Re: PR 13631 Problems in messages

2014-12-03 Thread Jonathan Wakely
On 02/12/14 23:58 +0100, François Dumont wrote: DR libstdc++/13631 s/DR/PR/ * include/bits/codecvt.h (codecvtchar, char, mbstate_t): friend class std::messageschar. (codecvtwchar_t, char, mbstate_t): friend class std::messageswchar_t. * config/locale/gnu/messages_member.h

Re: PR 13631 Problems in messages

2014-12-02 Thread Jonathan Wakely
On 01/12/14 22:42 +0100, François Dumont wrote: Hi Here is another proposal that consider all your remarks except one. I finally prefer to go with std::vector of pointers. Dynamically allocating Catalog_info allow to avoid numerous copies of locale when we find this pointer from the

Re: PR 13631 Problems in messages

2014-12-02 Thread François Dumont
So here is another proposal with all your remarks implemented. 2014-12-02 François Dumont fdum...@gcc.gnu.org DR libstdc++/13631 * include/bits/codecvt.h (codecvtchar, char, mbstate_t): friend class std::messageschar. (codecvtwchar_t, char, mbstate_t): friend class

Re: PR 13631 Problems in messages

2014-12-01 Thread François Dumont
Hi Here is another proposal that consider all your remarks except one. I finally prefer to go with std::vector of pointers. Dynamically allocating Catalog_info allow to avoid numerous copies of locale when we find this pointer from the catalog info. On 28/11/2014 11:49, Jonathan Wakely

Re: PR 13631 Problems in messages

2014-11-28 Thread Jonathan Wakely
On 27/11/14 23:19 +0100, François Dumont wrote: Hi Here is a revisited version. I finally go without compiling in C++11 as I prefer to use __builtin_alloca instead of using std::unique_ptr and heap memory. I also realized that I could use codecvt::max_length to know the max number of

Re: PR 13631 Problems in messages

2014-11-28 Thread Jonathan Wakely
On 28/11/14 10:49 +, Jonathan Wakely wrote: I think it's fine to say you can't have more than 2^31 open message catalogs, but we should for numeric_limitscatalog::max() before ... but we should *check* for ... doing anything and return -1 to say it couldn't be opened.

Re: PR 13631 Problems in messages

2014-11-27 Thread François Dumont
Hi Here is a revisited version. I finally go without compiling in C++11 as I prefer to use __builtin_alloca instead of using std::unique_ptr and heap memory. I also realized that I could use codecvt::max_length to know the max number of multibytes. Tested under Linux x86_64 with all

Re: PR 13631 Problems in messages

2014-11-24 Thread François Dumont
On 24/11/2014 01:23, Jonathan Wakely wrote: On 24/11/14 00:13 +0100, François Dumont wrote: Hello As we are at doing some evolution in the ABI I would like to take the opportunity to merge branch libstdcxx_so_7-2. The first fix was I don't think we want to merge everything, but it's

PR 13631 Problems in messages

2014-11-23 Thread François Dumont
Hello As we are at doing some evolution in the ABI I would like to take the opportunity to merge branch libstdcxx_so_7-2. The first fix was about a messages facet issue. So here is the version for the trunk which is the one from the branch plus management of the charset part. This way

Re: PR 13631 Problems in messages

2014-11-23 Thread Jonathan Wakely
On 24/11/14 00:13 +0100, François Dumont wrote: Hello As we are at doing some evolution in the ABI I would like to take the opportunity to merge branch libstdcxx_so_7-2. The first fix was I don't think we want to merge everything, but it's certainly worth looking to see if there are some