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

[Martin Schanzenbach]

On 10.12.22 22:04, Martin Schanzenbach wrote:
> 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
> > 

Correction: Of course those are C++-specific ifdef's it is just that
they are usually grouped with the emacsens ifdefs which is why that grep
is a reasonably good way to find this.

Br

> 
> 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
>