of Thu, 29 Jul 2010 21:48:35 -0400.
X-Mailer: MH-E 8.0.3; MH 6.8.4; GNU Emacs 22.3.1
Date: Thu, 29 Jul 2010 18:57:18 -0700
Message-ID: <8297.1280455...@tully.cs.berkeley.edu>
From: Paul Hilfinger
> This release was bootstrapped with the following tools:
> Autoconf 2.6
Paul Hilfinger wrote:
> > BTW: I observe that ISO C++ has a template function
> > std::uninitialized_copy, defined in , which ought to work for
> > copying a stack properly.
>
Hans Aberg wrote:
> The algorithm is
>for (; first != last; ++result, ++fir
f the
'new' expression, as opposed to this operator).
Paul Hilfinger
___
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
have
constructors or destructors" or something of the sort.
BTW: I observe that ISO C++ has a template function
std::uninitialized_copy, defined in , which ought to work for
copying a stack properly.
Paul Hilfinger
___
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
g the C skeleton (not lalr1.cc), tweaking the generated code
to expand the parser stack regardless of __cplusplus, and compiling with
C++ works in at least simple cases. What's the problem?
Thanks.
Paul Hilfinger
___
help-bison@gnu.org http://lis
sive lists?
4. How do we specify list constructors for * and +?
5. How do we supply a value for the empty case in A?
6. How do we supply a value for the ( ... ) construct in B?
Paul Hilfinger
___
help-bison@gnu.org http://lists.gnu.org/mailman/lis
) as the value of the ambiguous
construct. %merge also allows you to reject some interpretations on
context-sensitive grounds. When I say "allows you" I don't mean that
it provides specific facilities to do any of this, but rather that it
gives a parser structur
It's all
> buried somewhere in the mailing lists, but Paul Eggert probably knows the
> history best.
Well, the GDB people have eliminated all uses at this point. Forgive
my blasphemy, but we don't have to respond to all requests. Reporting
unused function arguments is a dubi
my wording because `it is also' creates a smoother transition from
> the previous paragraphs. Is that OK?
Sure.
Paul Hilfinger
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
> 1. I've documented the use of YYEOF, yylval, and yylloc in semantic
> actions. Was this intentionally omitted before? Why?
Nah, just never got around to it, I guess.
> +During deterministic @acronym{GLR} operation, the effect of @code{YYERROR}
> is
> +similar to its effect in an @acro
,
This seems to be the only use of ARGSUSED in the directory. I believe
that the custom in Bison has been to use YYUSE instead.
[Aside: Are people still using lint? I haven't in well over a decade,
now that we have ANSI-style C + gcc -Wall.]
Paul Hilfinger
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
ake steps to make it otherwise. Here the issue is works
that are produced by the operation of copyrighted software. I don't
know what the default status is of works produced by X's use of Y's
copyrighted programs, but I rather suspect that such products belong
to X unless
ord!
In short, I am strongly in favor of making the terms of use for Bison
output uniformly liberal across skeletons.
Paul Hilfinger
> This is most likely an error: The other skeleton files did not exist at the
> time that stuff was written. Akim Demaille is resposnible for the C++ file
13 matches
Mail list logo
