[PATCH 1/2] flex: Avoid REJECT name conflict.
REJECT is a reserved word in flex and REJECT is also used as %token in bison grammar. Rename REJECT to Reject in bison grammar to avoid name conflict. Same thing for ECHO but that does not seem to cause any conflicts ATM so leave as is. Also delete some dead code in flex output by using the apropiate %option statements. Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se> --- conf/cf-lex.l | 5 +++-- filter/config.Y | 4 ++-- proto/static/config.Y | 4 ++-- 3 files changed, 7 insertions(+), 6 deletions(-) diff --git a/conf/cf-lex.l b/conf/cf-lex.l index 3fe3c2e..6612d3c 100644 --- a/conf/cf-lex.l +++ b/conf/cf-lex.l @@ -25,7 +25,6 @@ */ %{ -#undef REJECT /* Avoid name clashes */ #include <errno.h> #include <stdlib.h> @@ -71,12 +70,14 @@ linpool *cfg_mem; int (*cf_read_hook)(byte *buf, unsigned int max); #define YY_INPUT(buf,result,max) result = cf_read_hook(buf, max); -#define YY_NO_UNPUT + #define YY_FATAL_ERROR(msg) cf_error(msg) %} %option noyywrap +%option nounput +%option noinput %x COMMENT CCOMM CLI diff --git a/filter/config.Y b/filter/config.Y index 7723658..cab5dbe 100644 --- a/filter/config.Y +++ b/filter/config.Y @@ -28,7 +28,7 @@ static int make_pair(int i1, int i2) CF_DECLS CF_KEYWORDS(FUNCTION, PRINT, PRINTN, UNSET, RETURN, - ACCEPT, REJECT, ERROR, QUITBIRD, + ACCEPT, Reject, ERROR, QUITBIRD, INT, BOOL, IP, PREFIX, PAIR, QUAD, SET, STRING, BGPMASK, BGPPATH, CLIST, IF, THEN, ELSE, CASE, TRUE, FALSE, @@ -506,7 +506,7 @@ term: break_command: QUITBIRD { $$ = F_QUITBIRD; } | ACCEPT { $$ = F_ACCEPT; } - | REJECT { $$ = F_REJECT; } + | Reject { $$ = F_REJECT; } | ERROR { $$ = F_ERROR; } | PRINT { $$ = F_NOP; } | PRINTN { $$ = F_NONL; } diff --git a/proto/static/config.Y b/proto/static/config.Y index a7e5016..20f07ed 100644 --- a/proto/static/config.Y +++ b/proto/static/config.Y @@ -16,7 +16,7 @@ static struct static_route *this_srt; CF_DECLS -CF_KEYWORDS(STATIC, ROUTE, VIA, DROP, REJECT, PROHIBIT, PREFERENCE) +CF_KEYWORDS(STATIC, ROUTE, VIA, DROP, Reject, PROHIBIT, PREFERENCE) CF_GRAMMAR @@ -54,7 +54,7 @@ stat_route: add_tail(&((struct static_config *) this_proto)->iface_routes, &this_srt->n); } | stat_route0 DROP { this_srt->dest = RTD_BLACKHOLE; } - | stat_route0 REJECT { this_srt->dest = RTD_UNREACHABLE; } + | stat_route0 Reject { this_srt->dest = RTD_UNREACHABLE; } | stat_route0 PROHIBIT { this_srt->dest = RTD_PROHIBIT; } ; -- 1.6.4.4
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se> --- nest/proto.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/nest/proto.c b/nest/proto.c index f55def5..46147a4 100644 --- a/nest/proto.c +++ b/nest/proto.c @@ -807,6 +807,7 @@ proto_do_show_stats(struct proto *p) s->exp_withdraws_received, s->exp_withdraws_accepted); } +#ifdef CONFIG_PIPE static void proto_do_show_pipe_stats(struct proto *p) { @@ -846,6 +847,7 @@ proto_do_show_pipe_stats(struct proto *p) s1->exp_withdraws_received, s1->imp_withdraws_invalid, s1->imp_withdraws_ignored, s1->imp_withdraws_accepted); } +#endif void proto_cmd_show(struct proto *p, unsigned int verbose, int cnt) -- 1.6.4.4
On 27.4.2010 11:21, Joakim Tjernlund wrote:
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Thank you. Added.
--- nest/proto.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/nest/proto.c b/nest/proto.c index f55def5..46147a4 100644 --- a/nest/proto.c +++ b/nest/proto.c @@ -807,6 +807,7 @@ proto_do_show_stats(struct proto *p) s->exp_withdraws_received, s->exp_withdraws_accepted); }
+#ifdef CONFIG_PIPE static void proto_do_show_pipe_stats(struct proto *p) { @@ -846,6 +847,7 @@ proto_do_show_pipe_stats(struct proto *p) s1->exp_withdraws_received, s1->imp_withdraws_invalid, s1->imp_withdraws_ignored, s1->imp_withdraws_accepted); } +#endif
void proto_cmd_show(struct proto *p, unsigned int verbose, int cnt)
On 27.4.2010 11:21, Joakim Tjernlund wrote:
REJECT is a reserved word in flex and REJECT is also used as %token in bison grammar. Rename REJECT to Reject in bison grammar to avoid name conflict. Same thing for ECHO but that does not seem to cause any conflicts ATM so leave as is.
Hmm, interesting. What king of problems does it cause to you? Ondrej
Also delete some dead code in flex output by using the apropiate %option statements.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se> --- conf/cf-lex.l | 5 +++-- filter/config.Y | 4 ++-- proto/static/config.Y | 4 ++-- 3 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/conf/cf-lex.l b/conf/cf-lex.l index 3fe3c2e..6612d3c 100644 --- a/conf/cf-lex.l +++ b/conf/cf-lex.l @@ -25,7 +25,6 @@ */
%{ -#undef REJECT /* Avoid name clashes */
#include <errno.h> #include <stdlib.h> @@ -71,12 +70,14 @@ linpool *cfg_mem; int (*cf_read_hook)(byte *buf, unsigned int max);
#define YY_INPUT(buf,result,max) result = cf_read_hook(buf, max); -#define YY_NO_UNPUT + #define YY_FATAL_ERROR(msg) cf_error(msg)
%}
%option noyywrap +%option nounput +%option noinput
%x COMMENT CCOMM CLI
diff --git a/filter/config.Y b/filter/config.Y index 7723658..cab5dbe 100644 --- a/filter/config.Y +++ b/filter/config.Y @@ -28,7 +28,7 @@ static int make_pair(int i1, int i2) CF_DECLS
CF_KEYWORDS(FUNCTION, PRINT, PRINTN, UNSET, RETURN, - ACCEPT, REJECT, ERROR, QUITBIRD, + ACCEPT, Reject, ERROR, QUITBIRD, INT, BOOL, IP, PREFIX, PAIR, QUAD, SET, STRING, BGPMASK, BGPPATH, CLIST, IF, THEN, ELSE, CASE, TRUE, FALSE, @@ -506,7 +506,7 @@ term: break_command: QUITBIRD { $$ = F_QUITBIRD; } | ACCEPT { $$ = F_ACCEPT; } - | REJECT { $$ = F_REJECT; } + | Reject { $$ = F_REJECT; } | ERROR { $$ = F_ERROR; } | PRINT { $$ = F_NOP; } | PRINTN { $$ = F_NONL; } diff --git a/proto/static/config.Y b/proto/static/config.Y index a7e5016..20f07ed 100644 --- a/proto/static/config.Y +++ b/proto/static/config.Y @@ -16,7 +16,7 @@ static struct static_route *this_srt;
CF_DECLS
-CF_KEYWORDS(STATIC, ROUTE, VIA, DROP, REJECT, PROHIBIT, PREFERENCE) +CF_KEYWORDS(STATIC, ROUTE, VIA, DROP, Reject, PROHIBIT, PREFERENCE)
CF_GRAMMAR
@@ -54,7 +54,7 @@ stat_route: add_tail(&((struct static_config *) this_proto)->iface_routes, &this_srt->n); } | stat_route0 DROP { this_srt->dest = RTD_BLACKHOLE; } - | stat_route0 REJECT { this_srt->dest = RTD_UNREACHABLE; } + | stat_route0 Reject { this_srt->dest = RTD_UNREACHABLE; } | stat_route0 PROHIBIT { this_srt->dest = RTD_PROHIBIT; } ;
Ondrej Filip <feela@network.cz> wrote on 2010/04/27 11:34:18:
On 27.4.2010 11:21, Joakim Tjernlund wrote:
REJECT is a reserved word in flex and REJECT is also used as %token in bison grammar. Rename REJECT to Reject in bison grammar to avoid name conflict. Same thing for ECHO but that does not seem to cause any conflicts ATM so leave as is.
Hmm, interesting. What king of problems does it cause to you?
I noticed the compile warning caused by it and looked for the reason. I didn't notice any problem but such conflicts are a bug waiting to happen so I tried to fix it. The best fix would be to prefix all tokens(say TOK_) so one doesn't risk conflicts but that was too much work and need to change the *.m4 files which I don't speak. Jocke
Ondrej Filip <feela@network.cz> wrote on 2010/04/27 11:34:18:
On 27.4.2010 11:21, Joakim Tjernlund wrote:
REJECT is a reserved word in flex and REJECT is also used as %token in bison grammar. Rename REJECT to Reject in bison grammar to avoid name conflict. Same thing for ECHO but that does not seem to cause any conflicts ATM so leave as is.
Hmm, interesting. What king of problems does it cause to you?
I noticed the compile warning caused by it and looked for the reason. I didn't notice any problem but such conflicts are a bug waiting to happen so I tried to fix it. The best fix would be to prefix all tokens(say TOK_) so one doesn't risk conflicts but that was too much work and need to change the *.m4 files which I don't speak.
BTW, the only warning I see ATM is cf-lex.c:1874: warning: 'yy_fatal_error' defined but not used and that one is impossible to get rid of(unless flex changes) Do you really need the #define YY_FATAL_ERROR(msg) cf_error(msg) in cf_flex.l?
Hello!
I noticed the compile warning caused by it and looked for the reason. I didn't notice any problem but such conflicts are a bug waiting to happen so I tried to fix it.
Again, the fix is uglier than the symptoms of the problem.
The best fix would be to prefix all tokens(say TOK_) so one doesn't risk conflicts
This looks like the proper way. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth main(){char *s="main(){char *s=%c%s%c;printf(s,34,s,34);}";printf(s,34,s,34);}
Martin Mares <mj@ucw.cz> wrote on 2010/04/27 23:34:18:
Hello!
I noticed the compile warning caused by it and looked for the reason. I didn't notice any problem but such conflicts are a bug waiting to happen so I tried to fix it.
Again, the fix is uglier than the symptoms of the problem.
Picky, you rather stare at that warning and the ugly #undef REJECT plus some potential bug yet to be found? That also limits some options to flex as it complains that REJECT is already in use(or some such, can't remember the exact message)
The best fix would be to prefix all tokens(say TOK_) so one doesn't risk conflicts
This looks like the proper way.
Yes, but that is over my head. Something for you guys that speak m4. Jocke
Hello!
Again, the fix is uglier than the symptoms of the problem.
Picky, you rather stare at that warning and the ugly #undef REJECT plus some potential bug yet to be found?
No, I would rather like to commit a proper fix, not an ugly hack, which tries to fix something which has never bitten anybody yet. Thanks for pointing out the problem, but your patch is unusable. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth And God said: E = 1/2mv^2 - Ze^2/r ...and there *WAS* light!
Martin Mares <mj@ucw.cz> wrote on 2010/04/27 23:47:01:
Hello!
Again, the fix is uglier than the symptoms of the problem.
Picky, you rather stare at that warning and the ugly #undef REJECT plus some potential bug yet to be found?
No, I would rather like to commit a proper fix, not an ugly hack, which tries to fix something which has never bitten anybody yet.
That choice does exist yet unless you plan to do it? This bug must have been there forever and no one has bothered to fix it yet so I don't think there will be one anytime soon. Meanwhile, this is a better workaround than the current one.
Martin Mares <mj@ucw.cz> wrote on 2010/04/27 23:47:01:
Hello!
Again, the fix is uglier than the symptoms of the problem.
Picky, you rather stare at that warning and the ugly #undef REJECT plus some potential bug yet to be found?
No, I would rather like to commit a proper fix, not an ugly hack, which tries to fix something which has never bitten anybody yet.
That choice does exist yet unless you plan to do it? This bug must have been there forever and no one has bothered to fix it yet so I don't think there will be one anytime soon. Meanwhile, this is a better workaround than the current one.
While we are in cf-lex.l, this looks like a bug: diff --git a/conf/cf-lex.l b/conf/cf-lex.l index 82f4c52..b1a60e4 100644 --- a/conf/cf-lex.l +++ b/conf/cf-lex.l @@ -111,7 +111,7 @@ WHITE [ \t] #endif } -0x{DIGIT}+ { +0x{XIGIT}+ { char *e; long int l; errno = 0;
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: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
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 <mj@ucw.cz> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Make $$$ fast. Learn Perl!
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 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 as "pretty" anymore? Jocke
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 as "pretty" anymore?
Why exactly do you consider the REJECT buggy? Does the documentation of flex forbid redefinition of REJECT? Sure, it is not elegant and it might cause bugs in the future (currently, I do not see any real bug), but your rename is not elegant either. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth main(){char *s="main(){char *s=%c%s%c;printf(s,34,s,34);}";printf(s,34,s,34);}
Martin Mares <mj@ucw.cz> 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 the bison token REJECT to Reject because it doesn't look as "pretty" anymore?
Why exactly do you consider the REJECT buggy? Does the documentation of flex forbid redefinition of REJECT?
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 introducing another. Generally speaking, your bug reports are very welcome, but patches which offer ugly kludges as solutions not so much. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth 98% of the time I am right. Why worry about the other 3%
Martin Mares <mj@ucw.cz> 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. Hence your patch is buggy.
The original workaround is "buggier"
Do not fix a problem by introducing another.
Generally speaking, your bug reports are very welcome, but patches which offer ugly kludges as solutions not so much.
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. Jocke
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 submit a proper fix as easily as the ugly one. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth The better the better, the better the bet.
Martin Mares <mj@ucw.cz> 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 the token name space.
No need to wait for me. You can submit a proper fix as easily as the ugly one.
If that is the best answer you can do then BIRD just gonna have to live with the existing uglier one. Jocke
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 indeed used, or unsetting them to indicate it actually is not used (e.g., `%option noyymore)'.
BTW, wouldn't a simple `%option noreject' suffice? Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth If the government wants us to respect the law, it should set a better example.
Martin Mares <mj@ucw.cz> 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 them (e.g., `%option reject)' to indicate the feature is indeed used, or unsetting them to indicate it actually is not used (e.g., `%option noyymore)'.
BTW, wouldn't a simple `%option noreject' suffice?
That would only get rid of the warning, but REJECT is still a reserved word(-Cf still fails). Better that nothing though.
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 well be a non-expanded argument to a macro, which should not be touched by flex at all.) Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth return(ECRAY); /* Program exited before being run */
Martin Mares <mj@ucw.cz> 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 you one day want to use REJECT(or ECHO) in flex, it breaks.
(BTW blindly detecting every occurrence of the substring "REJECT" in the C code snippets smells of a bug in flex. It might very well be a non-expanded argument to a macro, which should not be touched by flex at all.)
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. Yes, it would have been better if they had named them YYECHO YYREJECT and YYBEGIN but they didn't.
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 standard ;-) Does that mean that every occurrence of REJECT as a substring in the C code is interpreted by flex? Or does that mean an occurrence of REJECT as an identifier? Or as a C statement? Do you see any place in the flex doc which makes this clear? Historically, all dialects of lex I have ever seen define these constructs as C macros, so that they do not trigger in strings or in non-expanding macro parameters and it is possible to un-/redefine them. If flex suddenly started to scan the source for calls of these actions in a way which does not really respect C syntax, it is at least a breach of long tradition. Whether it is a breach of the specs, nobody can tell as the specs are utterly vague. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Martin Mares <mj@ucw.cz> 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 the C snippets contained in the C source)? Go read the C standard ;-)
Does that mean that every occurrence of REJECT as a substring in the C code is interpreted by flex?
Not likely, but I have never tested that.
Or does that mean an occurrence of REJECT as an identifier?
My money is on this one.
Or as a C statement?
Do you see any place in the flex doc which makes this clear?
No, but not so strange as flex/lex is way old.
Historically, all dialects of lex I have ever seen define these constructs as C macros, so that they do not trigger in strings or in non-expanding macro parameters and it is possible to un-/redefine them. If flex suddenly started to scan the source for calls of these actions in a way which does not really respect C syntax, it is at least a breach of long tradition. Whether it is a breach of the specs, nobody can tell as the specs are utterly vague.
Well, it must respect C syntax, how else can one use them in the code? Theoretically one could image that REJECT and friends are changed into some inline function but it would be very unpopular I think.
Martin Mares <mj@ucw.cz> 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 them (e.g., `%option reject)' to indicate the feature is indeed used, or unsetting them to indicate it actually is not used (e.g., `%option noyymore)'.
BTW, wouldn't a simple `%option noreject' suffice?
So what was the end conclusion on this, will you add %option noinput %option nounput %option noreject ? Then the only warning left is the one fixed with #define YY_FATAL_ERROR(msg) do {cf_error(msg); if(0) yy_fatal_error(msg); } while(0) Not ideal, but the try convincing flex of that :)
On Fri, Apr 30, 2010 at 06:29:22PM +0200, Joakim Tjernlund wrote:
So what was the end conclusion on this, will you add %option noinput %option nounput %option noreject ?
Yes, i merged that, together with some other suggested changes. Thanks.
Then the only warning left is the one fixed with #define YY_FATAL_ERROR(msg) do {cf_error(msg); if(0) yy_fatal_error(msg); } while(0) Not ideal, but the try convincing flex of that :)
This is ugly and unnecessary workaround, i would rather keep this warning. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Ondrej Zajicek <santiago@crfreenet.org> wrote on 2010/05/02 22:57:18:
On Fri, Apr 30, 2010 at 06:29:22PM +0200, Joakim Tjernlund wrote:
So what was the end conclusion on this, will you add %option noinput %option nounput %option noreject ?
Yes, i merged that, together with some other suggested changes. Thanks.
Then the only warning left is the one fixed with #define YY_FATAL_ERROR(msg) do {cf_error(msg); if(0) yy_fatal_error(msg); } while(0) Not ideal, but the try convincing flex of that :)
This is ugly and unnecessary workaround, i would rather keep this warning.
Well, it is a defect in flex, not likely to be fixed anytime soon, and the only remaining warning in the build. Would it not be good to remove that one too, even if it is somewhat ugly? Then one would start to pay attention to all warnings as there is normally no warnings. Jocke BTW, it seems like you git server is down?
On Sun, May 02, 2010 at 11:09:32PM +0200, Joakim Tjernlund wrote:
Then the only warning left is the one fixed with #define YY_FATAL_ERROR(msg) do {cf_error(msg); if(0) yy_fatal_error(msg); } while(0) Not ideal, but the try convincing flex of that :)
This is ugly and unnecessary workaround, i would rather keep this warning.
Well, it is a defect in flex, not likely to be fixed anytime soon, and the only remaining warning in the build. Would it not be good to remove that one too, even if it is somewhat ugly? Then one would start to pay attention to all warnings as there is normally no warnings.
I usually pay attention to new warnings even if there are some small number of old unimportant 'persistent' warnings like these from flex output.
BTW, it seems like you git server is down?
Yes, we will check that. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Ondrej Zajicek <santiago@crfreenet.org> wrote on 2010/05/02 23:30:24:
On Sun, May 02, 2010 at 11:09:32PM +0200, Joakim Tjernlund wrote:
Then the only warning left is the one fixed with #define YY_FATAL_ERROR(msg) do {cf_error(msg); if(0) yy_fatal_error (msg); } while(0) Not ideal, but the try convincing flex of that :)
This is ugly and unnecessary workaround, i would rather keep this warning.
Well, it is a defect in flex, not likely to be fixed anytime soon, and the only remaining warning in the build. Would it not be good to remove that one too, even if it is somewhat ugly? Then one would start to pay attention to all warnings as there is normally no warnings.
I usually pay attention to new warnings even if there are some small number of old unimportant 'persistent' warnings like these from flex output.
Not all are as you, especially newcomers. If there are warnings to begin with one might just ignore them altogether, not even noticing any new ones. Jocke
Hi, ----------- http://bird.network.cz/?get_doc&f=bird-6.html#ss6.1 "Route selection rules" ... Prefer the route with the lowest value of router ID of the advertising router. ----------- Our users wants to see "router ID" for every route in looking glass output. It is important for task to understand, why some route is best, while another one - not best. Is it possible to display "router ID" for every route in 'show route all...' output ? -- Mikhail A. Grishin E-mail: magr@ripn.net
Mikhail, On 17.05.2010 10:05 Mikhail A. Grishin wrote
Hi, ----------- http://bird.network.cz/?get_doc&f=bird-6.html#ss6.1 "Route selection rules" ... Prefer the route with the lowest value of router ID of the advertising router. -----------
Our users wants to see "router ID" for every route in looking glass output. It is important for task to understand, why some route is best, while another one - not best.
Is it possible to display "router ID" for every route in 'show route all...' output ?
iirc you are already massaging output from BIRD to present it in a more Cisco style to your customers. So why not including information from "show protocols all ..." as well? That's imho much better then overloading BIRD with funny stuff. Just my .02EUR, Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold@nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333
Hi Arnold, Arnold Nipper пишет:
Mikhail,
On 17.05.2010 10:05 Mikhail A. Grishin wrote
Hi, ----------- http://bird.network.cz/?get_doc&f=bird-6.html#ss6.1 "Route selection rules" ... Prefer the route with the lowest value of router ID of the advertising router. -----------
Our users wants to see "router ID" for every route in looking glass output. It is important for task to understand, why some route is best, while another one - not best.
Is it possible to display "router ID" for every route in 'show route all...' output ?
iirc you are already massaging output from BIRD to present it in a more Cisco style to your customers. So why not including information from "show protocols all ..." as well?
That's imho much better then overloading BIRD with funny stuff.
If it's impossible (or unwanted) to do it internally, we'll do it by parsing some other BIRD outputs. But another BGP attrubutes (med, as_path, local pref, ...), which make sense in BGP route selection process, already seen at "show protocols all" output, so may be logically more correct to add "router ID". -- Mikhail A. Grishin E-mail: magr@ripn.net
On 17.05.2010 13:01 Mikhail A. Grishin wrote
Hi Arnold,
Arnold Nipper пишет:
Mikhail,
On 17.05.2010 10:05 Mikhail A. Grishin wrote
Hi, ----------- http://bird.network.cz/?get_doc&f=bird-6.html#ss6.1 "Route selection rules" ... Prefer the route with the lowest value of router ID of the advertising router. -----------
Our users wants to see "router ID" for every route in looking glass output. It is important for task to understand, why some route is best, while another one - not best.
Is it possible to display "router ID" for every route in 'show route all...' output ?
iirc you are already massaging output from BIRD to present it in a more Cisco style to your customers. So why not including information from "show protocols all ..." as well?
That's imho much better then overloading BIRD with funny stuff.
If it's impossible (or unwanted) to do it internally, we'll do it by parsing some other BIRD outputs.
But another BGP attrubutes (med, as_path, local pref, ...), which make sense in BGP route selection process, already seen at "show protocols all" output, so may be logically more correct to add "router ID".
Not really ... med, as_path, local pref, ... are BGP path attributes, router ID isn't. Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold@nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333
On Mon, May 17, 2010 at 04:57:17PM +0200, Arnold Nipper wrote:
If it's impossible (or unwanted) to do it internally, we'll do it by parsing some other BIRD outputs.
But another BGP attrubutes (med, as_path, local pref, ...), which make sense in BGP route selection process, already seen at "show protocols all" output, so may be logically more correct to add "router ID".
Not really ... med, as_path, local pref, ... are BGP path attributes, router ID isn't.
Yes, that is the reason why router IDs are not shown here, as they are really 'attributes' of BGP peer, not route attributes. There are other BGP peer attributes that might take a part in best path selection process (like some configuration options) and they are also not shown here. So i would also suggest to use information from 'show protocols all'. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (7)
-
Arnold Nipper -
Joakim Tjernlund -
Joakim Tjernlund
-
Martin Mares -
Mikhail A. Grishin -
Ondrej Filip -
Ondrej Zajicek