This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add D demangling support to libiberty


On Tue, Oct 14, 2014 at 7:12 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>
>> libiberty/ChangeLog
>> 2014-08-05  Iain Buclaw  <ibuclaw@gdcproject.org>
>>
>>     * Makefile.in (CFILES): Add d-demangle.c.
>>     (REQUIRED_OFILES): Add d-demangle.o.
>>     * cplus-dem.c (libiberty_demanglers): Add dlang_demangling case.
>>     (cplus_demangle): Likewise.
>>     * d-demangle.c: New file.
>>     * testsuite/Makefile.in (really-check): Add check-d-demangle.
>>     * testsuite/d-demangle-expected: New file.
>
> As hinted on gdb-patches, this patch causes a GDB build failure
> on Solaris 2.9, because it uses strtold which is not available.
> According to gnulib's documentation, it should also break on
> the following systems:
>
>         NetBSD 3.0, OpenBSD 3.8, Minix 3.1.8, IRIX 6.5, OSF/1 4.0,
>         Solaris 9, Cygwin, MSVC 9, Interix 3.5, BeOS.
>
> This patch attempts to fix the issue by adding a configure check
> for strtold and adjusts the code to use strtod if strtold does not
> exist.
>
> Does this look OK to you? If yes, can one of the GCC maintainers
> please review?

It doesn't make sense to me to use strtod if strtold is required.  And
if strtold is not required, then it seems to me that we should always
use strtod.  It seems to me that the right options are either 1) use
strtod unconditionally; 2) add strtold to libiberty

Since option 1 is simpler, what bad things would happen if we use
strtod unconditionally?

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]