Hello!
> That choice does exist yet unless you plan to do it?
The choice exists: either leave the current work-around, or change it to
your work-around. Neither is a proper fix.
Have a nice fortnight
--
Martin `MJ' Mares http://mj.ucw.
>
> Hello!
>
> > That choice does exist yet unless you plan to do it?
>
> The choice exists: either leave the current work-around, or change it to
> your work-around. Neither is a proper fix.
Right, neither is an ideal fix but at least mine is "correct" and doesn't
cause REJECT to be defined insid
On Wed, Apr 28, 2010 at 09:07:29AM +0200, Joakim Tjernlund wrote:
> While we are in cf-lex.l, this looks like a bug:
> -0x{DIGIT}+ {
> +0x{XIGIT}+ {
Definitely, thank you. I will merge that bugfix.
--
Elen sila lumenn' omentielvo
Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org)
OpenPG
Hello!
> Right, neither is an ideal fix but at least mine is "correct" and doesn't
> cause REJECT to be defined inside flex, causing warnings.
>
> I don't understand your reasoning, you rather keep the buggy REJECT
> instead of renaming the bison token REJECT to Reject because it
> doesn't look a
Martin Mares wrote on 2010/04/29 17:57:44:
>
> Hello!
>
> > Right, neither is an ideal fix but at least mine is "correct" and doesn't
> > cause REJECT to be defined inside flex, causing warnings.
> >
> > I don't understand your reasoning, you rather keep the buggy REJECT
> > instead of renaming th
Hello!
> No, but it is the equivalent of renaming a variable from an ideal name
> to a less ideal name, not a big deal.
It's called breaking invariants. So far, all tokens were named in a uniform,
systematic way. Your patch breaks it. Hence your patch is buggy.
Do not fix a problem by introducin
Martin Mares wrote on 2010/04/29 19:23:22:
>
> Hello!
>
> > No, but it is the equivalent of renaming a variable from an ideal name
> > to a less ideal name, not a big deal.
>
> It's called breaking invariants. So far, all tokens were named in a uniform,
> systematic way. Your patch breaks it. Henc
Hello!
> I have moved the the workaround to where it belongs,
> in the grammar files. The current kludge masks potential bugs
> and causes compiler warnings and is a much worse workaround than the
> one I offer while we wait for you to fix the token name space.
No need to wait for me. You can su
Martin Mares wrote on 2010/04/29 20:44:26:
>
> Hello!
>
> > I have moved the the workaround to where it belongs,
> > in the grammar files. The current kludge masks potential bugs
> > and causes compiler warnings and is a much worse workaround than the
> > one I offer while we wait for you to fix t
Hello!
> `flex' scans your rule actions to determine whether you use the
> `REJECT' or `yymore()' features. The `REJECT' and `yymore' options are
> available to override its decision as to whether you use the options,
> either by setting them (e.g., `%option reject)' to indicate the feature
> is
Martin Mares wrote on 2010/04/29 22:14:16:
>
> Hello!
>
> > `flex' scans your rule actions to determine whether you use the
> > `REJECT' or `yymore()' features. The `REJECT' and `yymore' options are
> > available to override its decision as to whether you use the options,
> > either by setting th
Hello!
> That would only get rid of the warning, but REJECT is still
> a reserved word(-Cf still fails).
This should not be a problem as we don't use -Cf, should it?
(BTW blindly detecting every occurrence of the substring "REJECT" in the
C code snippets smells of a bug in flex. It might very we
Martin Mares wrote on 2010/04/29 22:37:13:
>
> Hello!
>
> > That would only get rid of the warning, but REJECT is still
> > a reserved word(-Cf still fails).
>
> This should not be a problem as we don't use -Cf, should it?
We don't. I just made a point that %noreject doesn't solve
everything. If
Ondrej, this looks buggy:
+static inline void htonlsab(void *h, void *n, u16 len) { memcpy(n, h, len); };
+static inline void ntohlsab(void *n, void *h, u16 len) { memcpy(h, n, len); };
memcpy is not defined to handle overlapping memory. Best to add:
if (n != h)
memcpy(...)
Might as well do t
On Thu, Apr 29, 2010 at 11:03:32PM +0200, Joakim Tjernlund wrote:
>
> Ondrej, this looks buggy:
>
> +static inline void htonlsab(void *h, void *n, u16 len) { memcpy(n, h, len);
> };
> +static inline void ntohlsab(void *n, void *h, u16 len) { memcpy(h, n, len);
> };
>
> memcpy is not defined to
Hello!
> Haven't you heard a word ? ECHO, REJECT and BEGIN are pre defined
> actions in flex that you can use in your C code. Go read flex again.
I know that. But what does that really means from the point of view
of C syntax (as used in the C snippets contained in the C source)?
Go read the C st
Ondrej Zajicek wrote on 2010/04/29 23:15:22:
>
> On Thu, Apr 29, 2010 at 11:03:32PM +0200, Joakim Tjernlund wrote:
> >
> > Ondrej, this looks buggy:
> >
> > +static inline void htonlsab(void *h, void *n, u16 len) { memcpy(n, h,
> > len); };
> > +static inline void ntohlsab(void *n, void *h, u16
Martin Mares wrote on 2010/04/29 23:21:48:
>
> Hello!
>
> > Haven't you heard a word ? ECHO, REJECT and BEGIN are pre defined
> > actions in flex that you can use in your C code. Go read flex again.
>
> I know that. But what does that really means from the point of view
> of C syntax (as used in t
>
> Ondrej Zajicek wrote on 2010/04/29 23:15:22:
> >
> > On Thu, Apr 29, 2010 at 11:03:32PM +0200, Joakim Tjernlund wrote:
> > >
> > > Ondrej, this looks buggy:
> > >
> > > +static inline void htonlsab(void *h, void *n, u16 len) { memcpy(n, h,
> > > len); };
> > > +static inline void ntohlsab(voi
19 matches
Mail list logo
