bug#34849: Compilation issues with g++ on some files

bug#34849: Compilation issues with g++ on some files

[Alex]

I'm currently working on a prototype for a feature that requires the
introduction of C++ files, and I am having some issues compiling certain
files with g++. Any chance the below (particularly #3) could be easily
fixed?

1. Invalid conversions to pvec_type. Compiling with the -fpermissive
flag demotes these to warnings, but it would be nice to avoid using
that.

--8<---------------cut here---------------start------------->8---
./src/lisp.h: In function ‘pvec_type PSEUDOVECTOR_TYPE(const Lisp_Vector*)’:
./src/lisp.h:1683:11: error: invalid conversion from ‘long int’ to ‘pvec_type’ [-fpermissive]
   return (size & PSEUDOVECTOR_FLAG
          ~~~~~~~~~~~~~~~~~~~~~~~~~
           ? (size & PVEC_TYPE_MASK) >> PSEUDOVECTOR_AREA_BITS
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           : PVEC_NORMAL_VECTOR);
           ~~~~~~~~~~~~~~~~~~~~~
./src/lisp.h: In function ‘bool PSEUDOVECTORP(Lisp_Object, int)’:
./src/lisp.h:1708:6: error: invalid conversion from ‘int’ to ‘pvec_type’ [-fpermissive]
      code);
      ^~~~
--8<---------------cut here---------------end--------------->8---

2. This one just needs a new (not new) variable name.

--8<---------------cut here---------------start------------->8---
./src/lisp.h:1585:58: error: expected ‘,’ or ‘...’ before ‘new’
 SSET (Lisp_Object string, ptrdiff_t index, unsigned char new)
                                                          ^~~
./src/lisp.h: In function ‘void SSET(Lisp_Object, ptrdiff_t, unsigned char)’:
./src/lisp.h:1587:30: error: expected type-specifier before ‘;’ token
   SDATA (string)[index] = new;
                              ^
--8<---------------cut here---------------end--------------->8---

3. I'm not sure what to do for the next one, which is unfortunately
included by other files.

--8<---------------cut here---------------start------------->8---
./lib/time.h:769:1: error: expected ‘,’ or ‘...’ before ‘__timer’
 _GL_FUNCDECL_SYS (localtime_rz, struct tm *,
 ^~~~~~~~~~~~~~~~
./lib/time.h:771:50: error: nonnull argument with out-of-range operand number (argument 2, operand 3)
                    struct tm *restrict __result) _GL_ARG_NONNULL ((2, 3)));
                                                  ^~~~~~~~~~~~~~~
./lib/time.h:775:1: error: expected ‘,’ or ‘...’ before ‘__result’
 _GL_FUNCDECL_SYS (mktime_z, time_t,
 ^~~~~~~~~~~~~~~~
--8<---------------cut here---------------end--------------->8---

bug#34849: Compilation issues with g++ on some files

[Alex]

Alex <agrambot@gmail.com> writes:

> I'm currently working on a prototype for a feature that requires the
> introduction of C++ files, and I am having some issues compiling certain
> files with g++. Any chance the below (particularly #3) could be easily
> fixed?
>
> 1. Invalid conversions to pvec_type. Compiling with the -fpermissive
> flag demotes these to warnings, but it would be nice to avoid using
> that.
>
> ./src/lisp.h: In function ‘pvec_type PSEUDOVECTOR_TYPE(const Lisp_Vector*)’:
> ./src/lisp.h:1683:11: error: invalid conversion from ‘long int’ to ‘pvec_type’ [-fpermissive]
>    return (size & PSEUDOVECTOR_FLAG
>           ~~~~~~~~~~~~~~~~~~~~~~~~~
>            ? (size & PVEC_TYPE_MASK) >> PSEUDOVECTOR_AREA_BITS
>            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>            : PVEC_NORMAL_VECTOR);
>            ~~~~~~~~~~~~~~~~~~~~~
> ./src/lisp.h: In function ‘bool PSEUDOVECTORP(Lisp_Object, int)’:
> ./src/lisp.h:1708:6: error: invalid conversion from ‘int’ to ‘pvec_type’ [-fpermissive]
>       code);
>       ^~~~
>
>
> 2. This one just needs a new (not new) variable name.
>
> ./src/lisp.h:1585:58: error: expected ‘,’ or ‘...’ before ‘new’
>  SSET (Lisp_Object string, ptrdiff_t index, unsigned char new)
>                                                           ^~~
> ./src/lisp.h: In function ‘void SSET(Lisp_Object, ptrdiff_t, unsigned char)’:
> ./src/lisp.h:1587:30: error: expected type-specifier before ‘;’ token
>    SDATA (string)[index] = new;
>                               ^
>
>
> 3. I'm not sure what to do for the next one, which is unfortunately
> included by other files.
>
> ./lib/time.h:769:1: error: expected ‘,’ or ‘...’ before ‘__timer’
>  _GL_FUNCDECL_SYS (localtime_rz, struct tm *,
>  ^~~~~~~~~~~~~~~~
> ./lib/time.h:771:50: error: nonnull argument with out-of-range operand number (argument 2, operand 3)
>                     struct tm *restrict __result) _GL_ARG_NONNULL ((2, 3)));
>                                                   ^~~~~~~~~~~~~~~
> ./lib/time.h:775:1: error: expected ‘,’ or ‘...’ before ‘__result’
>  _GL_FUNCDECL_SYS (mktime_z, time_t,
>  ^~~~~~~~~~~~~~~~

I managed to work around #3 by editing lib/time.h.in directly, but now
I've hit another issue: compiling lisp.h inside of an extern "C" block.
This gets me the following error:

--8<---------------cut here---------------start------------->8---
./lib/verify.h:178:1: error: template with C linkage
 template <int w>
--8<---------------cut here---------------end--------------->8---

Paul, do you have any ideas on how to fix this?  Is there a solution
that works both when __cplusplus is defined and when using C linkage?

bug#34849: Compilation issues with g++ on some files

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I'm currently working on a prototype for a feature that requires the
  > > introduction of C++ files,

What program is this a feature in?

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#34849: Compilation issues with g++ on some files

[Alex]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > > I'm currently working on a prototype for a feature that requires the
>   > > introduction of C++ files,
>
> What program is this a feature in?

I'm thinking about trying my hand at making a Qt [1] GUI for Emacs,
which is unfortunately written in C++.

The changes to the build system are minimal, and I've found workarounds
for the compilation issues I was having; however, proper solutions for
#1 and #3 are still missing.

[1] https://en.wikipedia.org/wiki/Qt_(software)

bug#34849: Compilation issues with g++ on some files

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I'm thinking about trying my hand at making a Qt [1] GUI for Emacs,
  > which is unfortunately written in C++.

There are two problems with that.

1. I don't want C++ code in the Emacs distribution.  This isn't the sort
of crucial thing that would override that general policy.

2. Qt is licensed under GPL 3 only.  If we ever need to make a GPL
version 4, we would release the next Emacs version under GPL 4-or-later,
so it could not be linked with Qt.

You can make the changes you wish, but we should not include it in
Emacs itself.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#34849: Compilation issues with g++ on some files

[Paul Eggert]

On 3/18/19 7:24 PM, Richard Stallman wrote:
> You can make the changes you wish, but we should not include it in
> Emacs itself.

With this in mind I plan to close the bug report with a wontfix.

bug#34849: Compilation issues with g++ on some files

[Alex]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > I'm thinking about trying my hand at making a Qt [1] GUI for Emacs,
>   > which is unfortunately written in C++.
>
> There are two problems with that.
>
> 1. I don't want C++ code in the Emacs distribution.  This isn't the sort
> of crucial thing that would override that general policy.

For the record, the addition of C++ was about as minimally invasive as
the Objective C code is, but I understand your desire to keep C++ out.

> 2. Qt is licensed under GPL 3 only.  If we ever need to make a GPL
> version 4, we would release the next Emacs version under GPL 4-or-later,
> so it could not be linked with Qt.
>
> You can make the changes you wish, but we should not include it in
> Emacs itself.

The licensing situation is unfortunate. Thank you for giving me notice
of this before spending much time on making it work.

bug#34849: Compilation issues with g++ on some files

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Mon, 18 Mar 2019 22:24:18 -0400
> Cc: eggert@cs.ucla.edu, 34849@debbugs.gnu.org
> 
> 1. I don't want C++ code in the Emacs distribution.  This isn't the sort
> of crucial thing that would override that general policy.

I believe the intent was to make the existing code be compilable with
a C++ compiler without introducing any C++ code per se.

My POV on this is that we should make Emacs buildable with as many
modern GUI toolkits as practically possible/reasonable, because it is
not clear which one(s) of them will remain workable and maintained in
the long run.  And since many/most of the toolkits and packages we'd
like to use or be compatible with are written in C++ (HarfBuzz is a
good recent example), we should try making our sources be more
friendly to C++ compilers, as much as possible, because not every such
package has a C glue, like HarfBuzz does.

Therefore, if integration with Qt is reasonably possible, we should
not reject it outright.  I understand the concerns regarding the
license, but we will need to revisit that when GPL's version is
advanced, and not sooner.  Disabling support for a package that no
longer satisfies our requirements is relatively easy.

bug#34849: Compilation issues with g++ on some files

[Paul Eggert]

Eli Zaretskii wrote:
> I believe the intent was to make the existing code be compilable with
> a C++ compiler without introducing any C++ code per se.

Although that may have been the intent, the downside is that a reasonable amount 
of work and testing would have to be done to support it. On the Gnulib side 
we've had some skepticism that this would be worth the hassle; see:

https://lists.gnu.org/r/bug-gnulib/2019-03/msg00060.html

Especially since there is a disciplined way of using the code that (at least for 
Alex's need) appears to work well enough; see:

https://lists.gnu.org/r/bug-gnulib/2019-03/msg00064.html

> many/most of the toolkits and packages we'd
> like to use or be compatible with are written in C++ (HarfBuzz is a
> good recent example)

Sure, but as you mentioned HarfBuzz has a C API, and we needn't tweak or revamp 
Emacs's C code in order to use HarfBuzz. In my experiences toolkits with a C++ 
API but without a C API tend to be less flexible and more of a hassle for C code 
to interface to, and it's not clear we should spend much time catering to them.

bug#34849: Compilation issues with g++ on some files

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > My POV on this is that we should make Emacs buildable with as many
  > modern GUI toolkits as practically possible/reasonable, because it is
  > not clear which one(s) of them will remain workable and maintained in
  > the long run.

That argument could be valid for toolkits that we could possibly use
in the long run.  Because of the possible future licensing conflict,
we cannot consider Qt as an option for the long run unless we convince
the Qt developers to change to GPL 3-or-later.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#34849: Compilation issues with g++ on some files

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

In general, license changes are exactly the sort of thing we need to
prepare fore before the need actually arises.

  >   I understand the concerns regarding the
  > license, but we will need to revisit that when GPL's version is
  > advanced, and not sooner.

That reasoning could be valid if we were dealing with computers only.
However, Emacs's users are humans.  If they form a habit, they will
oppose changing it.

I don't want there to be humans who insist that Emacs should stay
under GPL v3 so it can continue to be linked with Qt.

This problem could be resolved if Qt moves to GPL 3-or-later.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#34849: Compilation issues with g++ on some files

[Alex]

Paul Eggert <eggert@cs.ucla.edu> writes:

> Eli Zaretskii wrote:
>> I believe the intent was to make the existing code be compilable with
>> a C++ compiler without introducing any C++ code per se.
>
> Although that may have been the intent, the downside is that a reasonable amount
> of work and testing would have to be done to support it.

Perhaps in the long run, but outside of these few issues everything
_seemed_ fine, at least with my particular configuration.

> On the Gnulib side we've had some skepticism that this would be worth
> the hassle; see:
>
> https://lists.gnu.org/r/bug-gnulib/2019-03/msg00060.html
>
> Especially since there is a disciplined way of using the code that (at least for
> Alex's need) appears to work well enough; see:
>
> https://lists.gnu.org/r/bug-gnulib/2019-03/msg00064.html

My problem there was that lisp.h includes verify.h, so I figure it would
have been better to either fix it in upstream (which got shot down) or
wrap the single include in extern "C++" rather than wrap most of lisp.h
in extern "C".

bug#34849: Compilation issues with g++ on some files

[Eli Zaretskii]

> Cc: agrambot@gmail.com, 34849@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 19 Mar 2019 19:12:24 -0700
> 
> Especially since there is a disciplined way of using the code that (at least for 
> Alex's need) appears to work well enough; see:
> 
> https://lists.gnu.org/r/bug-gnulib/2019-03/msg00064.html

If this takes care of Alex's needs, it's fine with me.  But it isn't
always so, see, for example this:

  https://www.sourceware.org/ml/gdb-patches/2019-03/msg00143.html

where the GDB folks intend to solve this differently:

  https://www.sourceware.org/ml/gdb-patches/2019-03/msg00163.html

> > many/most of the toolkits and packages we'd
> > like to use or be compatible with are written in C++ (HarfBuzz is a
> > good recent example)
> 
> Sure, but as you mentioned HarfBuzz has a C API

That's just sheer luck, and is not indicative of other toolkits.  Qt
is a counter example of a widely used toolkit that AFAIK doesn't have
a C glue.

> In my experiences toolkits with a C++ API but without a C API tend
> to be less flexible and more of a hassle for C code to interface to,
> and it's not clear we should spend much time catering to them.

We are in the same situation with GTK (though not because of C++), and
experience teaches us that there's nothing we can do when upstream
developers decide to change their APIs in ways that adversely affect
us.

My point is that long-term Emacs survival strategy should favor
changes that make it easier to build with external toolkits.  E.g.,
even HarfBuzz needed non-trivial changes in how we handle character
composition.  Of course, such efforts might be infeasible, so there's
a judgment call that needs to be involved.  What I'm saying is that we
should favor such changes, unless they are prohibitively expensive,
not reject them unless they have negligible costs.  Gnulib's
perspective on this is different, and therefore what Gnulib decides is
not necessarily good policy for us.

bug#34849: Compilation issues with g++ on some files

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: eggert@cs.ucla.edu, 34849@debbugs.gnu.org, agrambot@gmail.com
> Date: Tue, 19 Mar 2019 22:31:46 -0400
> 
>   > My POV on this is that we should make Emacs buildable with as many
>   > modern GUI toolkits as practically possible/reasonable, because it is
>   > not clear which one(s) of them will remain workable and maintained in
>   > the long run.
> 
> That argument could be valid for toolkits that we could possibly use
> in the long run.  Because of the possible future licensing conflict,
> we cannot consider Qt as an option for the long run unless we convince
> the Qt developers to change to GPL 3-or-later.

But there's no conflict yet, is there?

Also, if Qt is installed on many systems as a system library, we could
use it as a system component, couldn't we?

bug#34849: Compilation issues with g++ on some files

[Eli Zaretskii]

> From: Alex <agrambot@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  rms@gnu.org,  34849@debbugs.gnu.org
> Date: Wed, 20 Mar 2019 00:04:09 -0600
> 
> > https://lists.gnu.org/r/bug-gnulib/2019-03/msg00064.html
> 
> My problem there was that lisp.h includes verify.h, so I figure it would
> have been better to either fix it in upstream (which got shot down) or
> wrap the single include in extern "C++" rather than wrap most of lisp.h
> in extern "C".

Why is it a problem to wrap most or all of lisp.h in extern "C"?  Most
of your system headers do that already.

bug#34849: Compilation issues with g++ on some files

[Dmitry Gutov]

On 20.03.2019 4:32, Richard Stallman wrote:

> That reasoning could be valid if we were dealing with computers only.
> However, Emacs's users are humans.  If they form a habit, they will
> oppose changing it.
> 
> I don't want there to be humans who insist that Emacs should stay
> under GPL v3 so it can continue to be linked with Qt.

The same users could argue for Qt to change the license, couldn't they?

bug#34849: Compilation issues with g++ on some files

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > But there's no conflict yet, is there?

The conflict exists now -- between keeping a vital option
unimpeded in the future, and inviting an impediment to it.

  > Also, if Qt is installed on many systems as a system library, we could
  > use it as a system component, couldn't we?

For distribution of executables on those specific systems, yes.  But
that doesn't eliminate the problem I'm concerned with.

My decision is still no.


-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#34849: Compilation issues with g++ on some files

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I don't want there to be humans who insist that Emacs should stay
  > > under GPL v3 so it can continue to be linked with Qt.

  > The same users could argue for Qt to change the license, couldn't they?

I suggest they do so now.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)