Re: List of all C++ incompatibility caused by extern C guards in 0.19.0

[Martin Schanzenbach]

On 10.12.22 06:11, Karl Semich wrote:
> On Sat, Dec 10, 2022 at 1:20 AM marty1885 <marty1885@protonmail.com> wrote:
> >
> > Hi,
> >
> > I found more C++ incompatibility while adding GNS support to my C++ 
> > program. I wiped a quick awk line to scan (by counting if there's an even 
> > count of guard attempts). It shows two more files have the same issue
> >
> > ```
> > ❯ cd /usr/include/gnunet
> > ❯ for f in `find . -type f`; do awk '/\/\* keep Emacse/{count += 1} END{ if 
> > (count % 2 != 0) print FILENAME}' $f; done
> > ./gnunet_gnsrecord_json_lib.h
> > ./gnu_name_system_record_flags.h
> > ./gnunet_container_lib.h
> > ```
> > gnunet_container_lib.h was reported in my previous post. I believe this is 
> > the entire list of files with bad extern C guards. Can someone with git 
> > access patch it?
> 
> Hi marty1885,
> 
> I’m not a part of gnunet, but I looked into your comment here for fun.
> 
> I did not find a previous post from you to this list to see what you
> are referring to. Where is the discussion?
> 
> I do not see how these guards would cause C++ incompatibility, given
> they are nonparsed and only affect emacsens. What error is being
> triggered?
> 
> k
> 

Hi Karl,

it's on the bug-gnunet mailing list: 
https://lists.gnu.org/archive/html/bug-gnunet/2022-12/threads.html
g++ may simply be a bit more picky about the ifdef mismatch.

Br
Martin