[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jim Meyering
Subject: Re: [PATCH 06/11] build: include <config.h> from lib/yyerror.c
Date: Mon, 23 Jan 2012 11:57:24 +0100

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.
>> 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;
        *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)
          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
 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 *);

 yyerror (char const *message)
-  return fprintf (stderr, "%s\n", message);
+  fputs (message, stderr);
+  fputc ('\n', stderr);

reply via email to

[Prev in Thread] Current Thread [Next in Thread]