Re: [PATCH 06/11] build: include <config.h> from lib/yyerror.c

[Jim Meyering]

Akim Demaille wrote:

> Le 18 janv. 2012 à 16:18, Jim Meyering a écrit :
>
>> Akim Demaille wrote:
>>> Le 18 janv. 2012 à 11:30, Jim Meyering a écrit :
>>>
>>>> From: Jim Meyering <address@hidden>
>>>>
>>>> * lib/yyerror.c: Include <config.h>.
>>>
>>> I suppose this is to get #define fprintf and such?
>>
>> Right, and maybe even "const" on some crufty old systems.
>
> Actually we have a problem here, and I don't know what
> is the best means to address it (the problem is not new, it's
> just more visible now).
>
> yyerror.c is not used to compile bison, but liby, which
> is there to please POSIX Yacc:
>
>> # The Yacc compatibility library.
>> lib_LIBRARIES = $(YACC_LIBRARY)
>> EXTRA_LIBRARIES = lib/liby.a
>> lib_liby_a_SOURCES = lib/main.c lib/yyerror.c
>
> If I link liby again libbison, it goes from 6k to 864k.
> What would you recommend?  I am personally in favor of
> #undef fprintf in yyerror.c.  Or maybe there is a simple
> means to cherry-pick what liby needs from gnulib?
>
> This problem exists for real.
>
> http://lists.gnu.org/archive/html/help-bison/2011-11/msg00000.html

Hi Akim,

How about this?
I didn't find anyone using the return value, so rather than
trying to preserve semantics for nonexistent callers, I opted
to make this yyerror function return void as documented.

Oh, wait!
I do see one non-void use.  It's in data/glr.c:

  return yyerror (]b4_yyerror_args[YY_("syntax error: cannot back up")),     \

>From the context, I'm not sure if that code is ever used:

    ------------------------------------------
    # undef YYBACKUP
    # define YYBACKUP(Token, Value)                                             
 \
      return yyerror (]b4_yyerror_args[YY_("syntax error: cannot back up")),    
 \
             yyerrok, yyerr

      yylow = 1;
      if (yyrhslen == 0)
        *yyvalp = yyval_default;
      else
        *yyvalp = yyvsp[YYFILL (1-yyrhslen)].yystate.yysemantics.yysval;
      YYLLOC_DEFAULT ((*yylocp), (yyvsp - yyrhslen), yyrhslen);
    ]b4_locations_if([[  yystackp->yyerror_range[1].yystate.yyloc = *yylocp;
    ]])[
      switch (yyn)
        {
          ]b4_user_actions[
          default: break;
        }

      return yyok;
    # undef yyerrok
    # undef YYABORT
    # undef YYACCEPT
    # undef YYERROR
    # undef YYBACKUP
    ------------------------------------------

Anyhow, with that I'm not so sure it's ok to s/int/void/.

If we want to keep the existing return valueu semantics, we can use a
combination of strlen, fwrite, and fputc, but with more logic to reliably
report how many bytes were output.  Not sure that's worth it.

What do you think?

>From a9b1b57767154f2414b9819720b3294cbf561895 Mon Sep 17 00:00:00 2001
From: Jim Meyering <address@hidden>
Date: Mon, 23 Jan 2012 11:47:46 +0100
Subject: [PATCH] avoid possibly-replaced fprintf in liby-source, yyerror.c

* lib/yyerror.c (yyerror): Use fputs and fputc rather than fprintf
with a mere "%s\n" format.  Also, change the return type to void.
This avoids a problem reported by Thiru Ramakrishnan in
http://lists.gnu.org/archive/html/help-bison/2011-11/msg00000.html
---
 lib/yyerror.c |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/lib/yyerror.c b/lib/yyerror.c
index 5eb339f..5ac0438 100644
--- a/lib/yyerror.c
+++ b/lib/yyerror.c
@@ -20,10 +20,11 @@
 #include <config.h>
 #include <stdio.h>

-int yyerror (char const *);
+void yyerror (char const *);

-int
+void
 yyerror (char const *message)
 {
-  return fprintf (stderr, "%s\n", message);
+  fputs (message, stderr);
+  fputc ('\n', stderr);
 }
--
1.7.9.rc2.2.g183d6