* doc/bison.texinfo: Update.

* doc/bison.1 (mandoc): Update.
* src/system.h (EXT_GUARD_C, EXT_STYPE_H): Remove .c and .h.
* src/files.c: Support output files extensions computing.
(src_extension): New static variable.
(header_extension): New static variable.
(tr): New function.
(get_extension_index): New function, gets the index of an extension
filename in a string.
(compute_exts_from_gf): New function, computes extensions from the
grammar file extension.
(compute_exts_from_src): New functions, computes extensions from the
C source file extension, file given by ``-o'' option.
(compute_base_names): Update.
(output_files): Update.

doc/bison.1

@@ -71,13 +71,22 @@ Unlike
 .IR yacc ,
 the generated files do not have fixed names, but instead use the prefix
 of the input file.
+Moreover, if you need to put 
+.IR C++
+code in the input file, you can end his name by a C++-like extension
+(.ypp or .y++), then bison will follow your extension to name the 
+output file (.cpp or .c++).
 For instance, a grammar description file named
-.B parse.y
+.B parse.yxx
 would produce the generated parser in a file named
-.BR parse.tab.c ,
+.BR parse.tab.cxx ,
 instead of
 .IR yacc 's
-.BR y.tab.c .
+.BR y.tab.c 
+or old 
+.IR Bison
+versions
+.BR parse.tab.c .
 .PP
 This description of the options that can be given to
 .I bison

doc/bison.info

@@ -32,9 +32,9 @@ instead of in the original English.
 Indirect:
 bison.info-1: 1307
 bison.info-2: 50189
-bison.info-3: 99779
-bison.info-4: 149657
-bison.info-5: 196400
+bison.info-3: 99814
+bison.info-4: 149692
+bison.info-5: 196961
 
 Tag Table:
 (Indirect)
@@ -71,69 +71,69 @@ Node: Mfcalc Rules72281
 Node: Mfcalc Symtab73661
 Node: Exercises80034
 Node: Grammar File80540
-Node: Grammar Outline81353
-Node: C Declarations82087
-Node: Bison Declarations82667
-Node: Grammar Rules83079
-Node: C Code83539
-Node: Symbols84469
-Node: Rules89550
-Node: Recursion91189
-Node: Semantics92908
-Node: Value Type94002
-Node: Multiple Types94674
-Node: Actions95691
-Node: Action Types98476
-Node: Mid-Rule Actions99779
-Node: Locations105348
-Node: Location Type106013
-Node: Actions and Locations106571
-Node: Location Default Action107735
-Node: Declarations108942
-Node: Token Decl110261
-Node: Precedence Decl112274
-Node: Union Decl113825
-Node: Type Decl114669
-Node: Expect Decl115575
-Node: Start Decl117121
-Node: Pure Decl117499
-Node: Decl Summary119176
-Node: Multiple Parsers124559
-Node: Interface126053
-Node: Parser Function126925
-Node: Lexical127760
-Node: Calling Convention129166
-Node: Token Values131937
-Node: Token Positions133086
-Node: Pure Calling133971
-Node: Error Reporting136903
-Node: Action Features139025
-Node: Algorithm142320
-Node: Look-Ahead144613
-Node: Shift/Reduce146745
-Node: Precedence149657
-Node: Why Precedence150308
-Node: Using Precedence152173
-Node: Precedence Examples153141
-Node: How Precedence153842
-Node: Contextual Precedence154991
-Node: Parser States156782
-Node: Reduce/Reduce158025
-Node: Mystery Conflicts161586
-Node: Stack Overflow164972
-Node: Error Recovery166345
-Node: Context Dependency171481
-Node: Semantic Tokens172329
-Node: Lexical Tie-ins175346
-Node: Tie-in Recovery176894
-Node: Debugging179066
-Node: Invocation182367
-Node: Bison Options183097
-Node: Environment Variables186531
-Node: Option Cross Key187379
-Node: VMS Invocation188223
-Node: Table of Symbols189007
-Node: Glossary196400
-Node: Index202690
+Node: Grammar Outline81388
+Node: C Declarations82122
+Node: Bison Declarations82702
+Node: Grammar Rules83114
+Node: C Code83574
+Node: Symbols84504
+Node: Rules89585
+Node: Recursion91224
+Node: Semantics92943
+Node: Value Type94037
+Node: Multiple Types94709
+Node: Actions95726
+Node: Action Types98511
+Node: Mid-Rule Actions99814
+Node: Locations105383
+Node: Location Type106048
+Node: Actions and Locations106606
+Node: Location Default Action107770
+Node: Declarations108977
+Node: Token Decl110296
+Node: Precedence Decl112309
+Node: Union Decl113860
+Node: Type Decl114704
+Node: Expect Decl115610
+Node: Start Decl117156
+Node: Pure Decl117534
+Node: Decl Summary119211
+Node: Multiple Parsers124594
+Node: Interface126088
+Node: Parser Function126960
+Node: Lexical127795
+Node: Calling Convention129201
+Node: Token Values131972
+Node: Token Positions133121
+Node: Pure Calling134006
+Node: Error Reporting136938
+Node: Action Features139060
+Node: Algorithm142355
+Node: Look-Ahead144648
+Node: Shift/Reduce146780
+Node: Precedence149692
+Node: Why Precedence150343
+Node: Using Precedence152208
+Node: Precedence Examples153176
+Node: How Precedence153877
+Node: Contextual Precedence155026
+Node: Parser States156817
+Node: Reduce/Reduce158060
+Node: Mystery Conflicts161621
+Node: Stack Overflow165007
+Node: Error Recovery166380
+Node: Context Dependency171516
+Node: Semantic Tokens172364
+Node: Lexical Tie-ins175381
+Node: Tie-in Recovery176929
+Node: Debugging179101
+Node: Invocation182402
+Node: Bison Options183658
+Node: Environment Variables187092
+Node: Option Cross Key187940
+Node: VMS Invocation188784
+Node: Table of Symbols189568
+Node: Glossary196961
+Node: Index203251
 
 End Tag Table

doc/bison.info-2

@@ -903,7 +903,7 @@ produces a C-language function that recognizes correct instances of the
 grammar.
 
    The Bison grammar input file conventionally has a name ending in
-`.y'.
+`.y'.  *Note Invoking Bison: Invocation.
 
 * Menu:
 

doc/bison.info-4

@@ -857,7 +857,20 @@ Invoking Bison
    Here INFILE is the grammar file name, which usually ends in `.y'.
 The parser file's name is made by replacing the `.y' with `.tab.c'.
 Thus, the `bison foo.y' filename yields `foo.tab.c', and the `bison
-hack/foo.y' filename yields `hack/foo.tab.c'.
+hack/foo.y' filename yields `hack/foo.tab.c'. It's is also possible, in
+case you are writting C++ code instead of C in your grammar file, to
+name it `foo.ypp' or `foo.y++'. Then, the output files will take an
+extention like the given one as input (repectively `foo.tab.cpp' and
+`foo.tab.c++').  This feature takes effect with all options that
+manipulate filenames like `-o' or `-d'.
+
+   For example :
+
+     bison -d INFILE.YXX
+   will produce `infile.tab.cxx' and `infile.tab.hxx'. and
+
+     bison -d INFILE.Y -o OUTPUT.C++
+   will produce `output.c++' and `outfile.h++'.
 
 * Menu:
 

doc/bison.texinfo

@@ -2142,6 +2142,7 @@ Bison takes as input a context-free grammar specification and produces a
 C-language function that recognizes correct instances of the grammar.
 
 The Bison grammar input file conventionally has a name ending in @samp{.y}.
+@xref{Invocation, ,Invoking Bison}.
 
 @menu
 * Grammar Outline::   Overall layout of the grammar file.
@@ -5079,7 +5080,26 @@ Here @var{infile} is the grammar file name, which usually ends in
 @samp{.y}.  The parser file's name is made by replacing the @samp{.y}
 with @samp{.tab.c}.  Thus, the @samp{bison foo.y} filename yields
 @file{foo.tab.c}, and the @samp{bison hack/foo.y} filename yields
-@file{hack/foo.tab.c}.@refill
+@file{hack/foo.tab.c}. It's is also possible, in case you are writting
+C++ code instead of C in your grammar file, to name it @file{foo.ypp} 
+or @file{foo.y++}. Then, the output files will take an extention like
+the given one as input (repectively @file{foo.tab.cpp} and @file{foo.tab.c++}).
+This feature takes effect with all options that manipulate filenames like
+@samp{-o} or @samp{-d}.
+
+For example :
+
+@example
+bison -d @var{infile.yxx}
+@end example
+will produce @file{infile.tab.cxx} and @file{infile.tab.hxx}. and
+
+@example
+bison -d @var{infile.y} -o @var{output.c++}
+@end example
+will produce @file{output.c++} and @file{outfile.h++}.
+
+@refill
 
 @menu
 * Bison Options::     All the options described in detail,

doc/stamp-vti

@@ -1,3 +1,3 @@
-@set UPDATED 30 July 2001
+@set UPDATED 1 August 2001
 @set EDITION 1.28a
 @set VERSION 1.28a

doc/version.texi

@@ -1,3 +1,3 @@
-@set UPDATED 30 July 2001
+@set UPDATED 1 August 2001
 @set EDITION 1.28a
 @set VERSION 1.28a