[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: No header guard in glr.c skeleton (bison 2.4.1)
From: |
Alexandre Bique |
Subject: |
Re: No header guard in glr.c skeleton (bison 2.4.1) |
Date: |
Sat, 4 Apr 2009 01:22:54 +0100 |
On Mon, Jan 19, 2009 at 9:27 PM, Akim Demaille <address@hidden> wrote:
> Le 17 janv. 09 à 02:29, Alexandre Bique a écrit :
>
>> Hi,
>>
>> I just patched glr.c skeleton because it generates header without guards.
>> I attached the patch.
>
> Hi Alexandre.
>
> Thank you for the patch. Unfortunately the cure is nastier than the
> disease: you used a constant string as a header guard, which will make life
> harder for people who mix several parsers.
Well, i just updated my patch. It use b4_prefix and translate [a-z:]
-> [A-Z_]. I think it should work with people who mix several parsers.
> But you definitely have a point here, we should do something. As a matter
> of fact, even the plain old yacc-like header does not have include-guards.
I checked the git repository and i haven't find any commit related to
this issue. But i may have missed it.
> We'll address this.
>
>> Thank you for bison.
>
> Thank you for saying!
>
> Out of curiosity, what are you using glr.c for?
For the fun ;-) But i should use glr.cc because I do C++. But I feel
that the C interface is simpler to use. I wonder if it is difficult to
maintain skeletons for the C and C++, and if one is more performant
than another ?
Thank you.
PS: the patch is against bison 2.4.1
--
Alexandre Bique
glr.c-header-guard.patch
Description: Binary data
- Re: No header guard in glr.c skeleton (bison 2.4.1),
Alexandre Bique <=