Re: Bison "comparison is always true due to limited range of data type"

[Akim Demaille]

| When running "make check" with the latest CVS version of Bison, I
| discovered the following failure:
| 
|    30. synclines.at:91: testing Prologue synch line...
|    synclines.at:91: $CC $CFLAGS $CPPFLAGS -c syncline.c || (exit 1)
|    stderr:
|    syncline.c:1:2: #error "1"
|    synclines.at:91: sed 's/^\([^:]*:[^:.]*\)[.:][^:]*:\(.*\)$/\1:\2/' stderr
|    stdout:
|    syncline.c:1: #error "1"
|    synclines.at:91: test "`cat stdout`" = 'syncline.c:1: #error "1"' || exit 
77
|    synclines.at:91: bison input.y -o input.c
|    synclines.at:91: $CC $CFLAGS $CPPFLAGS -c input.c || (exit 1)
|    stderr:
|    input.y:2:2: #error "2"
|    input.c: In function `yyparse':
|    input.c:807: warning: comparison is always true due to limited range of 
data type
|    ...
| 
| In a way, it's nice that GCC discovers that the comparison is useless
| in a toy example, but in real code I don't think it's worth worrying
| about any optimization here since the comparison won't be useless.  So
| I installed the following patch to work around this problem.

Arg.  I was about to talk about this issue.  I'm not sure it's only in
case of toy grammars actually, and also, I much prefer the old colde
which was more readable (to my eyes).  I was about to ask whether
issuing the code via M4 code was a good thing or not.

| 
| 2002-10-13  Paul Eggert  <address@hidden>
| 
|       * data/yacc.c (yyparse): Rewrite to avoid "comparison is always
|       true due to limited range of data type" warning from GCC.
| 
| diff -p -u -r1.17 -r1.18
| --- yacc.c    13 Oct 2002 14:25:14 -0000      1.17
| +++ yacc.c    14 Oct 2002 06:54:41 -0000      1.18
| @@ -918,27 +918,19 @@ yybackup:
|        YYDPRINTF ((stderr, "\n"));
|      }
|  
| -  /* Set YYN to the action to take in STATE on seeing token YYCHAR1.
| -     Result YYN means
| -     - YYN < 0:  Reduce on rule -YYN.
| -     - YYN = 0:  Error.
| -     - YYN > 0:  Shift to state YYN.  */
| +  /* If the proper action on seeing token YYCHAR1 is to reduce or to
| +     detect an error, take that action.  */
|    yyn += yychar1;
|    if (yyn < 0 || YYLAST < yyn || yycheck[yyn] != yychar1)
| -    /* Defaulted action (reduction).  */
| -    yyn = -yydefact[yystate];
| -  else if (yytable[yyn] != YYTABLE_NINF)
| -    yyn = yytable[yyn];
| -  else
| -    yyn = 0;
| -
| -  if (yyn < 0)
| +    goto yydefault;
| +  yyn = yytable[yyn];
| +  if (yyn <= 0)
|      {
| +      if (yyn == 0 || yyn == YYTABLE_NINF)
| +     goto yyerrlab;
|        yyn = -yyn;
|        goto yyreduce;
|      }
| -  else if (yyn == 0)
| -    goto yyerrlab;
|  
|    if (yyn == YYFINAL)
|      YYACCEPT;

Well, after all not, why not.  But then, could you adjust the GLR code
so that it looks the same?  It should also trigger the same error
IIRC.  Unfortunately I can't check now: I'm at EPITA, and the student
who lent me his ADSL left with his portable computer.  He should be
back today...