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