On 10.12.22 06:11, Karl Semich wrote:
> On Sat, Dec 10, 2022 at 1:20 AM marty1885 <marty1...@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
