headers
Jim Michaels | 16 Oct 23:40
Picon
Favicon
Gravatar

Fw: problems with bison-flex

see below.  cannot rename output files to .cpp and compile with C++ compiler.  compiler chokes.
using bison 2.1 and flex 2.5.4.  there is no later version available via gnuwin32 package.  cannot use cygwin.

 
Jim Michaels
jmichae3 <at> yahoo.com
http://JesusnJim.com

On Wed, 15 Oct 2008, Jim Michaels wrote:

> well, I used C versions of everything like you said to do, and made them .cpp files.
> I have some problems.  bison & flex can't stand themselves.
> 
> 
>     b->yy_is_interactive = file ? (isatty( fileno(file) ) > 0) : 0;
> Error E2015 lex.yy.cpp 5696: Ambiguity between 'std::isatty(int)' and 'isatty(int)' in function
yy_init_buffer(yy_buffer_state *,std::FILE *)
> *** 1 errors in Compile ***
> parser.tab.cpp:
> 
> extern "C" {
> #  endif
> #  ifndef YYMALLOC
> #   define YYMALLOC malloc
> #   if (! defined (malloc) && ! defined (YYINCLUDED_STDLIB_H) \
>     && (defined (__STDC__) || defined (__cplusplus)))
> void *malloc (YYSIZE_T); /* INFRINGES ON USER NAME SPACE */
> #   endif
> #  endif
> #  ifndef YYFREE
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel E. Denny | 21 Oct 16:56

Re: Bug in replacing strndup

As far as I can tell, this message was never delivered, so I'm resending.

On Sat, 18 Oct 2008, Joel E. Denny wrote:

> On Wed, 3 Sep 2008, Esa A E Peuha wrote:
> 
> > Replacing libc function strndup during building of Bison 2.3 doesn't
> > work quite right; if the configure script determines that libc has
> > non-working strndup, then lib/strndup.o defines symbol `strndup' while
> > other .o files refer to symbol `rpl_strndup', and compilation halts with
> > this message:
> > 
> > ../lib/libbison.a(xstrndup.o)(.text+0x5): In function `xstrndup':
> > .../bison-2.3/lib/xstrndup.c:35: undefined reference to `rpl_strndup'
> 
> Thanks for the report.  This appears to be a bug in Gnulib that's already 
> been fixed.  I am able to reproduce the behavior in Bison 2.3 by altering 
> my configure script to assign gl_cv_func_strndup=no wherever it previously 
> assigned yes.  I am not able to reproduce it with the latest git sources 
> for Bison and Gnulib.
> 
> If you would like to be sure this is fixed for you, you can build Bison 
> from our latest git sources:
> 
>   http://savannah.gnu.org/projects/bison/
> 
> Alternatively, you could download our latest test release, bison-2.3b, 
> which I believe also has the fix:
> 
>   http://alpha.gnu.org/gnu/bison/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel E. Denny | 21 Oct 16:56

Re: C++ template lalr1.cc: one use of location instead of location_type

As far as I can tell, this message was never delivered, so I'm resending.

On Sat, 18 Oct 2008, Joel E. Denny wrote:

> On Sun, 31 Aug 2008, Georg Sauthoff wrote:
> 
> > I noticed, that in the C++ parser template class lalr1.cc is one usage
> > of 'location' hardcoded instead of the user configurable type-synonym
> > 'location_type'.
> 
> > location yyerror_range[2];
> 
> > 1. just replace 'location' with 'location_type', like in the rest of the
> >    lalr1.cc.
> 
> Looks reasonable.  I pushed the following fix.  Thanks for the report.
> 
> > 2. do 1. and extend yy::location with a virtual method which does this
> >    computation (-> user can over-load this function if needed when
> >    extending yy::location)
> 
> This sounds like a new feature rather than a fix, so I think it should 
> wait until after the 2.4 release.  Even then, I'll probably just leave it 
> up to Akim Demaille, who wrote the C++ skeletons.
> 
> >From 0f0e1ace602fd8ded2457b1ea4f73c8fb2bfc6cc Mon Sep 17 00:00:00 2001
> From: Joel E. Denny <jdenny <at> ces.clemson.edu>
> Date: Sat, 18 Oct 2008 12:46:12 -0400
> Subject: [PATCH] Fix yyerror_range for user-defined location type in C++.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jim Michaels | 24 Oct 02:26
Picon
Favicon
Gravatar

%locations C output in 2.1

in version 2.1, the output you get from doing a 
%locations
I don't know if it is supposed to do only C++ output or not, but under C output it produces the following
uncompilable C code, which appears to be a direct M4 macro.

b4_pure_if(,
extern YYSTYPE b4_prefix[]lval;)

b4_location_if(
#if ! defined (YYLTYPE) && ! defined (YYLTYPE_IS_DECLARED)
typedef struct YYLTYPE
{
  int first_line;
  int first_column;
  int last_line;
  int last_column;
} YYLTYPE;
# define yyltype YYLTYPE /* obsolescent; will be withdrawn */
# define YYLTYPE_IS_DECLARED 1
# define YYLTYPE_IS_TRIVIAL 1
#endif

m4_if(b4_pure, [0],
[extern YYLTYPE b4_prefix[]lloc;])
)

 
Jim Michaels
jmichae3 <at> yahoo.com
http://JesusnJim.com
(Continue reading)

Permalink | Reply | 1 comment |
headers
Akim Demaille | 26 Oct 12:10
Picon
Picon
Picon
Gravatar

Re: %locations C output in 2.1


Le 24 oct. 08 à 02:26, Jim Michaels a écrit :

> in version 2.1, the output you get from doing a
> %locations
> I don't know if it is supposed to do only C++ output or not, but  
> under C output it produces the following uncompilable C code, which  
> appears to be a direct M4 macro.

That's really weird, I don't remember there was such a bug.  Maybe a  
problem bw different M4s?  Anyway, the current release, 2.3, does not  
seem to have such a problem.
Permalink | Reply | 0 comments |

Gmane