[dev-context] luametatex compiled with g++

Hans Hagen j.hagen at xs4all.nl
Mon Dec 12 19:38:36 CET 2022

On 12/12/2022 2:11 PM, Schultheis Erik wrote:

> I'm not sure if this is the right list, if not please redirect me.

this list or the general context list

> So, I tried compiling luametatex using g++, and noticed some things that 
> prevent it from also being considered valid C++ code.

ok, but keep in mind that we try to avoid c++ specifics

> Two general problems are:
> 1) Initialization order. C++ wants initializers to be specified in the 
> order in which they will actually initialize the object, i.e. in the 
> order of the members.

Do you have a list of locations?

> 2) Reserved names. Some variables are named `class` or `template`, which 
> of course, breaks C++.

i'll replace these (but you need to check it as i don't compile with g++

> But more interesting are the specific pieces of code that get rejected, 
> because C++ is a bit more strict than C in some cases.

interesting; we compile with clang, gcc and msvc and each has its own 
(sometimes conflicting) messages

> 3) We get one complaint about comparing a pointer to an integer using <, 
> which  I believe is an actual bug in the code.

ok, fixed

> 4) A second complaint is about dropping const in `tex_to_cstring`. I 
> don't think this causes an actual error in the program, though.

hm, changes but let's see what othjer compilers say

> 5) Some of the `goto`s cause problems, because the jump skips over the 
> initialization of variables in the target scope. Again, these variables 
> are not used, so I don't think there is an actual error. The easy fix 
> here is to just move the code from the `goto` target into its own 
> function, which is probably better for readability anyway.

adapted (slightly different)

> 6) The last problem is that things break with g++ if the marco 
> `infinity` is defined.

adapted but best check if i didn't make mistakes there

> I've attached patches for 3), 4), and 5), as I think that these benefit 
> code quality in general. I can also send ones for 1) and 2), if there is 
> interest. 6) seems to be a more general incompatibility, I'm not sure if 
> there is a "fix" that doesn't require #if s.

you can check (1) and (2) next upload; we really try to avoid compiler 
specific #if's


                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
        tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl

More information about the dev-context mailing list