linux-kernel - Re: [PATCH v2] kbuild: support byacc as alternative YACC to bison

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMEGPiraGzabPXUzWVNDFkkJ-4rLD00uyMnE44Kgebu5ht6t2g@mail.gmail.com>
Date:   Sun, 3 Nov 2019 15:30:11 -0500
From:   Ethan Sommer <e5ten.arch@...il.com>
To:     Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc:     Michal Marek <michal.lkml@...kovi.net>,
        Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        Sedat Dilek <sedat.dilek@...il.com>,
        Nathan Chancellor <natechancellor@...il.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        DTML <devicetree@...r.kernel.org>
Subject: Re: [PATCH v2] kbuild: support byacc as alternative YACC to bison

> Hmm, this is unfortunate since there is no common way to
> specify the header path directly.
>
> I am not sure how much effort we should invent
> to support non-GNU implementation
> since we already rely on various GNU tools.
>
> If we decide to support byacc,
> we must carry the restriction
> that bans GNU-extension.

I just realized that I accidentally only responded to Masahiro with my
previous email from a few days ago so I'll just quote it here:
"I feel like changing 10 lines to support a different yacc
implementation that supports most of the GNU-specific features here
isn't the same thing as banning all GNU extensions, and in regards to
the file prefix, the method in my patch creates the same file names as
the bison-specific one for the 3 cases it is used for, and the flags
used for it are POSIX yacc compatible. In my opinion increasing
compatibility shouldn't have to be all or nothing, and it makes sense to
make changes that increase compatibility without outright banning GNU
extensions entirely."

Aside from that, patch to dtc has just been applied, so pulling the latest
upstream changes as well as the v2 of this patch should be what would be
needed to support byacc.