On 11/21/2016 11:27 PM, Bruno Haible wrote:
> Pedro Alves wrote:
>> How about breaking this line like the rpl method was breaking it, in order
>> to avoid overly-long lines?
>>
>>inline operator type () const
>>{ return reinterpret_cast((rettype2 (*)
>> parameters2)(::func)
Pedro Alves wrote:
> How about breaking this line like the rpl method was breaking it, in order
> to avoid overly-long lines?
>
>inline operator type () const
>{ return reinterpret_cast((rettype2 (*)
> parameters2)(::func)); }
>
> Likewise the other similar cases.
If lin
On 11/20/2016 12:26 PM, Bruno Haible wrote:
> Hi Pedro,
Hi!
> I added ChangeLog entries for your two patches from 2016-11-12
> (that Paul committed).
Thanks! Should I assume you're all using git-merge-changelog and
include ChangeLog changes in the diff as well as in the
commit log?
> The membe
Hi Pedro,
> Currently, with C++ namespace support enabled, by defining
> GNULIB_NAMESPACE, the replacement symbols put in the GNULIB_NAMESPACE
> namespace are function pointers that point to the rpl_func functions.
> This means that the linker must pull in the rpl_func functions, even
> when "GNUL
Thanks, I installed your two recent patches. I don't know C++ well; perhaps
Bruno or another reviewer can double-check if they have the time.
I noticed that with the patches installed, the command './gnulib-tool --test
--with-c++-tests frexp frexpl frexpf frexp-nolibm' fails with diagnostics li
Currently, with C++ namespace support enabled, by defining
GNULIB_NAMESPACE, the replacement symbols put in the GNULIB_NAMESPACE
namespace are function pointers that point to the rpl_func functions.
This means that the linker must pull in the rpl_func functions, even
when "GNULIB_NAMESPACE::func(..
