[09/36] floatformat.h: Wrap in extern "C".

  Just like libiberty.h.  So that C++ programs, such as GDB when built
as a C++ program, can use it.

include/ChangeLog:
2015-02-09  Pedro Alves  <palves@redhat.com>

	* floatformat.h [__cplusplus]: Wrap in extern "C".
---
 include/floatformat.h | 8 ++++++++
 1 file changed, 8 insertions(+)
  

On Mon, Feb 9, 2015 at 3:20 PM, Pedro Alves <palves@redhat.com> wrote:
> Just like libiberty.h.  So that C++ programs, such as GDB when built
> as a C++ program, can use it.

Why is not needed for GCC building with C++ compiler?

Thanks,
Andrew

>
> include/ChangeLog:
> 2015-02-09  Pedro Alves  <palves@redhat.com>
>
>         * floatformat.h [__cplusplus]: Wrap in extern "C".
> ---
>  include/floatformat.h | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/include/floatformat.h b/include/floatformat.h
> index 6b559864..71d332b 100644
> --- a/include/floatformat.h
> +++ b/include/floatformat.h
> @@ -20,6 +20,10 @@ Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA 02110-1301, USA.
>  #if !defined (FLOATFORMAT_H)
>  #define FLOATFORMAT_H 1
>
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
>  #include "ansidecl.h"
>
>  /* A floatformat consists of a sign bit, an exponent and a mantissa.  Once the
> @@ -148,4 +152,8 @@ floatformat_from_double (const struct floatformat *, const double *, void *);
>  extern int
>  floatformat_is_valid (const struct floatformat *fmt, const void *from);
>
> +#ifdef __cplusplus
> +}
> +#endif
> +
>  #endif /* defined (FLOATFORMAT_H) */
> --
> 1.9.3
>
  

On 02/09/2015 11:35 PM, Andrew Pinski wrote:
> On Mon, Feb 9, 2015 at 3:20 PM, Pedro Alves <palves@redhat.com> wrote:
>> Just like libiberty.h.  So that C++ programs, such as GDB when built
>> as a C++ program, can use it.
> 
> Why is not needed for GCC building with C++ compiler?

Because it doesn't include it.

The header of the file claims it is part of GDB, though MAINTAINERS
nowadays says that everything under include/ is owned by GCC.

Thanks,
Pedro Alves
  

On Mon, Feb 9, 2015 at 3:49 PM, Pedro Alves <palves@redhat.com> wrote:
> On 02/09/2015 11:35 PM, Andrew Pinski wrote:
>> On Mon, Feb 9, 2015 at 3:20 PM, Pedro Alves <palves@redhat.com> wrote:
>>> Just like libiberty.h.  So that C++ programs, such as GDB when built
>>> as a C++ program, can use it.
>>
>> Why is not needed for GCC building with C++ compiler?
>
> Because it doesn't include it.
>
> The header of the file claims it is part of GDB, though MAINTAINERS
> nowadays says that everything under include/ is owned by GCC.

Wait, what?

The actual wording is:
"The rule is that if the file exists in the gcc tree then gcc owns it."
It originated from this thread,
https://sourceware.org/ml/gdb/2013-11/msg00025.html
That's not the first message in the thread, but that's where
I remember wanting to see something written down.

Perhaps kinda unfortunate for things like include/gdb/gdb-index.h.
But at least it's a rule that can be expressed in one sentence,
and I don't think it's been a problem.
  

On 02/14/2015 05:29 PM, Doug Evans wrote:
> On Mon, Feb 9, 2015 at 3:49 PM, Pedro Alves <palves@redhat.com> wrote:
>> On 02/09/2015 11:35 PM, Andrew Pinski wrote:
>>> Why is not needed for GCC building with C++ compiler?
>>
>> Because it doesn't include it.
>>
>> The header of the file claims it is part of GDB, though MAINTAINERS
>> nowadays says that everything under include/ is owned by GCC.
>
> Wait, what?
>
> The actual wording is:
> "The rule is that if the file exists in the gcc tree then gcc owns it."

I was paraphrasing, and simplified it.  That distinction seems
irrelevant to me here because the file does exist in the gcc tree.
It's necessary to build libiberty (for libiberty/floatformat.o).

It's a fact that the header claims it is part of GDB:

~~~~~~
/* IEEE floating point support declarations, for GDB, the GNU Debugger.
   Copyright (C) 1991-2015 Free Software Foundation, Inc.

This file is part of GDB.
(...)
~~~~~~

I guess it should say that it is part of libiberty instead.

> It originated from this thread,
> https://sourceware.org/ml/gdb/2013-11/msg00025.html
> That's not the first message in the thread, but that's where
> I remember wanting to see something written down.
>
> Perhaps kinda unfortunate for things like include/gdb/gdb-index.h.
> But at least it's a rule that can be expressed in one sentence,
> and I don't think it's been a problem.

I'm confused -- I didn't say it was a problem, nor expressed any
concern with the rule.  I just was pointing out facts.

ISTM that the procedure here is to push this change first through
the gcc repo first, and then merge it to binutils-gdb git.  Is that
wrong?

Thanks,
Pedro Alves
  

On Sat, Feb 14, 2015 at 10:36 AM, Pedro Alves <palves@redhat.com> wrote:
> On 02/14/2015 05:29 PM, Doug Evans wrote:
>> On Mon, Feb 9, 2015 at 3:49 PM, Pedro Alves <palves@redhat.com> wrote:
>>> On 02/09/2015 11:35 PM, Andrew Pinski wrote:
>>>> Why is not needed for GCC building with C++ compiler?
>>>
>>> Because it doesn't include it.
>>>
>>> The header of the file claims it is part of GDB, though MAINTAINERS
>>> nowadays says that everything under include/ is owned by GCC.
>>
>> Wait, what?
>>
>> The actual wording is:
>> "The rule is that if the file exists in the gcc tree then gcc owns it."
>
> I was paraphrasing, and simplified it.  That distinction seems
> irrelevant to me here because the file does exist in the gcc tree.
> It's necessary to build libiberty (for libiberty/floatformat.o).

No worries, I just wanted to make sure it didn't say something
it shouldn't.

> It's a fact that the header claims it is part of GDB:
>
> ~~~~~~
> /* IEEE floating point support declarations, for GDB, the GNU Debugger.
>    Copyright (C) 1991-2015 Free Software Foundation, Inc.
>
> This file is part of GDB.
> (...)
> ~~~~~~
>
> I guess it should say that it is part of libiberty instead.

At the least the current wording is confusing.

>> It originated from this thread,
>> https://sourceware.org/ml/gdb/2013-11/msg00025.html
>> That's not the first message in the thread, but that's where
>> I remember wanting to see something written down.
>>
>> Perhaps kinda unfortunate for things like include/gdb/gdb-index.h.
>> But at least it's a rule that can be expressed in one sentence,
>> and I don't think it's been a problem.
>
> I'm confused -- I didn't say it was a problem, nor expressed any
> concern with the rule.  I just was pointing out facts.

I didn't say you said it was a problem.
It was just an offhand comment about the rule itself,
not anything you said.

> ISTM that the procedure here is to push this change first through
> the gcc repo first, and then merge it to binutils-gdb git.  Is that
> wrong?

That's the procedure as I understand it.