head	1.3;
access;
symbols
	RELENG_8_4:1.3.0.2
	RELENG_9_1_0_RELEASE:1.2.42.1.4.2
	RELENG_9_1:1.2.42.1.0.4
	RELENG_9_1_BP:1.2.42.1
	RELENG_8_3_0_RELEASE:1.2.36.1.8.1
	RELENG_8_3:1.2.36.1.0.8
	RELENG_8_3_BP:1.2.36.1
	RELENG_9_0_0_RELEASE:1.2.42.1.2.1
	RELENG_9_0:1.2.42.1.0.2
	RELENG_9_0_BP:1.2.42.1
	RELENG_9:1.2.0.42
	RELENG_9_BP:1.2
	RELENG_7_4_0_RELEASE:1.2.40.1
	RELENG_8_2_0_RELEASE:1.2.36.1.6.1
	RELENG_7_4:1.2.0.40
	RELENG_7_4_BP:1.2
	RELENG_8_2:1.2.36.1.0.6
	RELENG_8_2_BP:1.2.36.1
	RELENG_8_1_0_RELEASE:1.2.36.1.4.1
	RELENG_8_1:1.2.36.1.0.4
	RELENG_8_1_BP:1.2.36.1
	RELENG_7_3_0_RELEASE:1.2.38.1
	RELENG_7_3:1.2.0.38
	RELENG_7_3_BP:1.2
	RELENG_8_0_0_RELEASE:1.2.36.1.2.1
	RELENG_8_0:1.2.36.1.0.2
	RELENG_8_0_BP:1.2.36.1
	RELENG_8:1.2.0.36
	RELENG_8_BP:1.2
	RELENG_7_2_0_RELEASE:1.2.34.1
	RELENG_7_2:1.2.0.34
	RELENG_7_2_BP:1.2
	RELENG_7_1_0_RELEASE:1.2.32.1
	RELENG_6_4_0_RELEASE:1.2.30.1
	RELENG_7_1:1.2.0.32
	RELENG_7_1_BP:1.2
	RELENG_6_4:1.2.0.30
	RELENG_6_4_BP:1.2
	RELENG_7_0_0_RELEASE:1.2
	RELENG_6_3_0_RELEASE:1.2
	RELENG_7_0:1.2.0.28
	RELENG_7_0_BP:1.2
	RELENG_6_3:1.2.0.26
	RELENG_6_3_BP:1.2
	RELENG_7:1.2.0.24
	RELENG_7_BP:1.2
	RELENG_6_2_0_RELEASE:1.2
	RELENG_6_2:1.2.0.22
	RELENG_6_2_BP:1.2
	RELENG_5_5_0_RELEASE:1.2
	RELENG_5_5:1.2.0.20
	RELENG_5_5_BP:1.2
	RELENG_6_1_0_RELEASE:1.2
	RELENG_6_1:1.2.0.18
	RELENG_6_1_BP:1.2
	RELENG_6_0_0_RELEASE:1.2
	RELENG_6_0:1.2.0.16
	RELENG_6_0_BP:1.2
	RELENG_6:1.2.0.14
	RELENG_6_BP:1.2
	RELENG_5_4_0_RELEASE:1.2
	RELENG_5_4:1.2.0.12
	RELENG_5_4_BP:1.2
	RELENG_5_3_0_RELEASE:1.2
	RELENG_5_3:1.2.0.10
	RELENG_5_3_BP:1.2
	RELENG_5:1.2.0.8
	RELENG_5_BP:1.2
	RELENG_5_2_1_RELEASE:1.2
	RELENG_5_2_0_RELEASE:1.2
	RELENG_5_2:1.2.0.6
	RELENG_5_2_BP:1.2
	RELENG_5_1_0_RELEASE:1.2
	RELENG_5_1:1.2.0.4
	RELENG_5_1_BP:1.2
	RELENG_5_0_0_RELEASE:1.2
	RELENG_5_0:1.2.0.2
	RELENG_5_0_BP:1.2;
locks; strict;
comment	@# @;


1.3
date	2012.11.17.01.50.29;	author svnexp;	state Exp;
branches
	1.3.2.1;
next	1.2;

1.2
date	2002.05.19.05.14.02;	author grog;	state Exp;
branches
	1.2.14.1
	1.2.24.1
	1.2.30.1
	1.2.32.1
	1.2.34.1
	1.2.36.1
	1.2.38.1
	1.2.40.1
	1.2.42.1;
next	1.1;

1.1
date	2002.05.19.04.37.39;	author grog;	state Exp;
branches;
next	;

1.3.2.1
date	2012.11.17.01.50.29;	author svnexp;	state dead;
branches;
next	1.3.2.2;

1.3.2.2
date	2013.03.28.13.03.41;	author svnexp;	state Exp;
branches;
next	;

1.2.14.1
date	2012.11.17.07.41.29;	author svnexp;	state Exp;
branches;
next	;

1.2.24.1
date	2012.11.17.08.03.49;	author svnexp;	state Exp;
branches;
next	;

1.2.30.1
date	2008.10.02.02.57.24;	author kensmith;	state Exp;
branches;
next	;

1.2.32.1
date	2008.11.25.02.59.29;	author kensmith;	state Exp;
branches;
next	;

1.2.34.1
date	2009.04.15.03.14.26;	author kensmith;	state Exp;
branches;
next	;

1.2.36.1
date	2009.08.03.08.13.06;	author kensmith;	state Exp;
branches
	1.2.36.1.2.1
	1.2.36.1.4.1
	1.2.36.1.6.1
	1.2.36.1.8.1;
next	1.2.36.2;

1.2.36.2
date	2012.11.17.10.36.18;	author svnexp;	state Exp;
branches;
next	;

1.2.36.1.2.1
date	2009.10.25.01.10.29;	author kensmith;	state Exp;
branches;
next	;

1.2.36.1.4.1
date	2010.06.14.02.09.06;	author kensmith;	state Exp;
branches;
next	;

1.2.36.1.6.1
date	2010.12.21.17.09.25;	author kensmith;	state Exp;
branches;
next	;

1.2.36.1.8.1
date	2012.03.03.06.15.13;	author kensmith;	state Exp;
branches;
next	1.2.36.1.8.2;

1.2.36.1.8.2
date	2012.11.17.08.24.58;	author svnexp;	state Exp;
branches;
next	;

1.2.38.1
date	2010.02.10.00.26.20;	author kensmith;	state Exp;
branches;
next	;

1.2.40.1
date	2010.12.21.17.10.29;	author kensmith;	state Exp;
branches;
next	1.2.40.2;

1.2.40.2
date	2012.11.17.08.16.56;	author svnexp;	state Exp;
branches;
next	;

1.2.42.1
date	2011.09.23.00.51.37;	author kensmith;	state Exp;
branches
	1.2.42.1.2.1
	1.2.42.1.4.1;
next	1.2.42.2;

1.2.42.2
date	2012.11.17.11.36.34;	author svnexp;	state Exp;
branches;
next	;

1.2.42.1.2.1
date	2011.11.11.04.20.22;	author kensmith;	state Exp;
branches;
next	1.2.42.1.2.2;

1.2.42.1.2.2
date	2012.11.17.08.36.33;	author svnexp;	state Exp;
branches;
next	;

1.2.42.1.4.1
date	2012.08.05.23.54.33;	author kensmith;	state Exp;
branches;
next	1.2.42.1.4.2;

1.2.42.1.4.2
date	2012.11.17.08.47.23;	author svnexp;	state Exp;
branches;
next	;


desc
@@


1.3
log
@Switching exporter and resync
@
text
@.\" Copyright (C) Caldera International Inc. 2001-2002.  All rights reserved.
.\" 
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions are
.\" met:
.\" 
.\" Redistributions of source code and documentation must retain the above
.\" copyright notice, this list of conditions and the following
.\" disclaimer.
.\" 
.\" Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 
.\" All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" 
.\" This product includes software developed or owned by Caldera
.\" International, Inc.  Neither the name of Caldera International, Inc.
.\" nor the names of other contributors may be used to endorse or promote
.\" products derived from this software without specific prior written
.\" permission.
.\" 
.\" USE OF THE SOFTWARE PROVIDED FOR UNDER THIS LICENSE BY CALDERA
.\" INTERNATIONAL, INC.  AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR
.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
.\" WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
.\" DISCLAIMED.  IN NO EVENT SHALL CALDERA INTERNATIONAL, INC. BE LIABLE
.\" FOR ANY DIRECT, INDIRECT INCIDENTAL, SPECIAL, EXEMPLARY, OR
.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
.\" BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
.\" WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
.\" OR OTHERWISE) RISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
.\" IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
.\"
.\"	@@(#)ss0	8.1 (Berkeley) 6/8/93
.\"
.\" $FreeBSD: head/share/doc/psd/15.yacc/ss0 96913 2002-05-19 05:14:02Z grog $
.SH
0: Introduction
.PP
Yacc provides a general tool for imposing structure on the input to a computer program.
The Yacc user prepares a
specification of the input process; this includes rules
describing the input structure, code to be invoked when these
rules are recognized, and a low-level routine to do the
basic input.
Yacc then generates a function to control the input process.
This function, called a
.I parser ,
calls the user-supplied low-level input routine
(the
.I "lexical analyzer" )
to pick up the basic items
(called
.I tokens )
from the input stream.
These tokens are organized according to the input structure rules,
called
.I "grammar rules" \|;
when one of these rules has been recognized,
then user code supplied for this rule, an
.I action ,
is invoked; actions have the ability to return values and
make use of the values of other actions.
.PP
Yacc is written in a portable dialect of C
.[
Ritchie Kernighan Language Prentice
.]
and the actions, and output subroutine, are in C as well.
Moreover, many of the syntactic conventions of Yacc follow C.
.PP
The heart of the input specification is a collection of grammar rules.
Each rule describes an allowable structure and gives it a name.
For example, one grammar rule might be
.DS
date  :  month\_name  day  \',\'  year   ;
.DE
Here,
.I date ,
.I month\_name ,
.I day ,
and
.I year
represent structures of interest in the input process;
presumably,
.I month\_name ,
.I day ,
and
.I year
are defined elsewhere.
The comma ``,'' is enclosed in single quotes; this implies that the
comma is to appear literally in the input.
The colon and semicolon merely serve as punctuation in the rule, and have
no significance in controlling the input.
Thus, with proper definitions, the input
.DS
July  4, 1776
.DE
might be matched by the above rule.
.PP
An important part of the input process is carried out by the
lexical analyzer.
This user routine reads the input stream, recognizing the lower level structures,
and communicates these tokens
to the parser.
For historical reasons, a structure recognized by the lexical analyzer is called a
.I "terminal symbol" ,
while the structure recognized by the parser is called a
.I "nonterminal symbol" .
To avoid confusion, terminal symbols will usually be referred to as
.I tokens .
.PP
There is considerable leeway in deciding whether to recognize structures using the lexical
analyzer or grammar rules.
For example, the rules
.DS
month\_name  :  \'J\' \'a\' \'n\'   ;
month\_name  :  \'F\' \'e\' \'b\'   ;

         . . .

month\_name  :  \'D\' \'e\' \'c\'   ;
.DE
might be used in the above example.
The lexical analyzer would only need to recognize individual letters, and
.I month\_name
would be a nonterminal symbol.
Such low-level rules tend to waste time and space, and may
complicate the specification beyond Yacc's ability to deal with it.
Usually, the lexical analyzer would
recognize the month names,
and return an indication that a
.I month\_name
was seen; in this case,
.I month\_name
would be a token.
.PP
Literal characters such as ``,'' must also be passed through the lexical
analyzer, and are also considered tokens.
.PP
Specification files are very flexible.
It is realively easy to add to the above example the rule
.DS
date  :  month \'/\' day \'/\' year   ;
.DE
allowing
.DS
7 / 4 / 1776
.DE
as a synonym for
.DS
July 4, 1776
.DE
In most cases, this new rule could be ``slipped in'' to a working system with minimal effort,
and little danger of disrupting existing input.
.PP
The input being read may not conform to the
specifications.
These input errors are detected as early as is theoretically possible with a
left-to-right scan;
thus, not only is the chance of reading and computing with bad
input data substantially reduced, but the bad data can usually be quickly found.
Error handling,
provided as part of the input specifications,
permits the reentry of bad data,
or the continuation of the input process after skipping over the bad data.
.PP
In some cases, Yacc fails to produce a parser when given a set of
specifications.
For example, the specifications may be self contradictory, or they may
require a more powerful recognition mechanism than that available to Yacc.
The former cases represent design errors;
the latter cases
can often be corrected
by making
the lexical analyzer
more powerful, or by rewriting some of the grammar rules.
While Yacc cannot handle all possible specifications, its power
compares favorably with similar systems;
moreover, the
constructions which are difficult for Yacc to handle are
also frequently difficult for human beings to handle.
Some users have reported that the discipline of formulating valid
Yacc specifications for their input revealed errors of
conception or design early in the program development.
.PP
The theory underlying Yacc has been described elsewhere.
.[
Aho Johnson Surveys LR Parsing
.]
.[
Aho Johnson Ullman Ambiguous Grammars
.]
.[
Aho Ullman Principles Compiler Design
.]
Yacc has been extensively used in numerous practical applications,
including
.I lint ,
.[
Johnson Lint
.]
the Portable C Compiler,
.[
Johnson Portable Compiler Theory
.]
and a system for typesetting mathematics.
.[
Kernighan Cherry typesetting system CACM
.]
.PP
The next several sections describe the
basic process of preparing a Yacc specification;
Section 1 describes the preparation of grammar rules,
Section 2 the preparation of the user supplied actions associated with these rules,
and Section 3 the preparation of lexical analyzers.
Section 4 describes the operation of the parser.
Section 5 discusses various reasons why Yacc may be unable to produce a
parser from a specification, and what to do about it.
Section 6 describes a simple mechanism for
handling operator precedences in arithmetic expressions.
Section 7 discusses error detection and recovery.
Section 8 discusses the operating environment and special features
of the parsers Yacc produces.
Section 9 gives some suggestions which should improve the
style and efficiency of the specifications.
Section 10 discusses some advanced topics, and Section 11 gives
acknowledgements.
Appendix A has a brief example, and Appendix B gives a
summary of the Yacc input syntax.
Appendix C gives an example using some of the more advanced
features of Yacc, and, finally,
Appendix D describes mechanisms and syntax
no longer actively supported, but
provided for historical continuity with older versions of Yacc.
@


1.3.2.1
log
@file ss0 was added on branch RELENG_8_4 on 2013-03-28 13:03:41 +0000
@
text
@d1 238
@


1.3.2.2
log
@## SVN ## Exported commit - http://svnweb.freebsd.org/changeset/base/248810
## SVN ## CVS IS DEPRECATED: http://wiki.freebsd.org/CvsIsDeprecated
@
text
@a0 238
.\" Copyright (C) Caldera International Inc. 2001-2002.  All rights reserved.
.\" 
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions are
.\" met:
.\" 
.\" Redistributions of source code and documentation must retain the above
.\" copyright notice, this list of conditions and the following
.\" disclaimer.
.\" 
.\" Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 
.\" All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" 
.\" This product includes software developed or owned by Caldera
.\" International, Inc.  Neither the name of Caldera International, Inc.
.\" nor the names of other contributors may be used to endorse or promote
.\" products derived from this software without specific prior written
.\" permission.
.\" 
.\" USE OF THE SOFTWARE PROVIDED FOR UNDER THIS LICENSE BY CALDERA
.\" INTERNATIONAL, INC.  AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR
.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
.\" WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
.\" DISCLAIMED.  IN NO EVENT SHALL CALDERA INTERNATIONAL, INC. BE LIABLE
.\" FOR ANY DIRECT, INDIRECT INCIDENTAL, SPECIAL, EXEMPLARY, OR
.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
.\" BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
.\" WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
.\" OR OTHERWISE) RISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
.\" IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
.\"
.\"	@@(#)ss0	8.1 (Berkeley) 6/8/93
.\"
.\" $FreeBSD: releng/8.4/share/doc/psd/15.yacc/ss0 96913 2002-05-19 05:14:02Z grog $
.SH
0: Introduction
.PP
Yacc provides a general tool for imposing structure on the input to a computer program.
The Yacc user prepares a
specification of the input process; this includes rules
describing the input structure, code to be invoked when these
rules are recognized, and a low-level routine to do the
basic input.
Yacc then generates a function to control the input process.
This function, called a
.I parser ,
calls the user-supplied low-level input routine
(the
.I "lexical analyzer" )
to pick up the basic items
(called
.I tokens )
from the input stream.
These tokens are organized according to the input structure rules,
called
.I "grammar rules" \|;
when one of these rules has been recognized,
then user code supplied for this rule, an
.I action ,
is invoked; actions have the ability to return values and
make use of the values of other actions.
.PP
Yacc is written in a portable dialect of C
.[
Ritchie Kernighan Language Prentice
.]
and the actions, and output subroutine, are in C as well.
Moreover, many of the syntactic conventions of Yacc follow C.
.PP
The heart of the input specification is a collection of grammar rules.
Each rule describes an allowable structure and gives it a name.
For example, one grammar rule might be
.DS
date  :  month\_name  day  \',\'  year   ;
.DE
Here,
.I date ,
.I month\_name ,
.I day ,
and
.I year
represent structures of interest in the input process;
presumably,
.I month\_name ,
.I day ,
and
.I year
are defined elsewhere.
The comma ``,'' is enclosed in single quotes; this implies that the
comma is to appear literally in the input.
The colon and semicolon merely serve as punctuation in the rule, and have
no significance in controlling the input.
Thus, with proper definitions, the input
.DS
July  4, 1776
.DE
might be matched by the above rule.
.PP
An important part of the input process is carried out by the
lexical analyzer.
This user routine reads the input stream, recognizing the lower level structures,
and communicates these tokens
to the parser.
For historical reasons, a structure recognized by the lexical analyzer is called a
.I "terminal symbol" ,
while the structure recognized by the parser is called a
.I "nonterminal symbol" .
To avoid confusion, terminal symbols will usually be referred to as
.I tokens .
.PP
There is considerable leeway in deciding whether to recognize structures using the lexical
analyzer or grammar rules.
For example, the rules
.DS
month\_name  :  \'J\' \'a\' \'n\'   ;
month\_name  :  \'F\' \'e\' \'b\'   ;

         . . .

month\_name  :  \'D\' \'e\' \'c\'   ;
.DE
might be used in the above example.
The lexical analyzer would only need to recognize individual letters, and
.I month\_name
would be a nonterminal symbol.
Such low-level rules tend to waste time and space, and may
complicate the specification beyond Yacc's ability to deal with it.
Usually, the lexical analyzer would
recognize the month names,
and return an indication that a
.I month\_name
was seen; in this case,
.I month\_name
would be a token.
.PP
Literal characters such as ``,'' must also be passed through the lexical
analyzer, and are also considered tokens.
.PP
Specification files are very flexible.
It is realively easy to add to the above example the rule
.DS
date  :  month \'/\' day \'/\' year   ;
.DE
allowing
.DS
7 / 4 / 1776
.DE
as a synonym for
.DS
July 4, 1776
.DE
In most cases, this new rule could be ``slipped in'' to a working system with minimal effort,
and little danger of disrupting existing input.
.PP
The input being read may not conform to the
specifications.
These input errors are detected as early as is theoretically possible with a
left-to-right scan;
thus, not only is the chance of reading and computing with bad
input data substantially reduced, but the bad data can usually be quickly found.
Error handling,
provided as part of the input specifications,
permits the reentry of bad data,
or the continuation of the input process after skipping over the bad data.
.PP
In some cases, Yacc fails to produce a parser when given a set of
specifications.
For example, the specifications may be self contradictory, or they may
require a more powerful recognition mechanism than that available to Yacc.
The former cases represent design errors;
the latter cases
can often be corrected
by making
the lexical analyzer
more powerful, or by rewriting some of the grammar rules.
While Yacc cannot handle all possible specifications, its power
compares favorably with similar systems;
moreover, the
constructions which are difficult for Yacc to handle are
also frequently difficult for human beings to handle.
Some users have reported that the discipline of formulating valid
Yacc specifications for their input revealed errors of
conception or design early in the program development.
.PP
The theory underlying Yacc has been described elsewhere.
.[
Aho Johnson Surveys LR Parsing
.]
.[
Aho Johnson Ullman Ambiguous Grammars
.]
.[
Aho Ullman Principles Compiler Design
.]
Yacc has been extensively used in numerous practical applications,
including
.I lint ,
.[
Johnson Lint
.]
the Portable C Compiler,
.[
Johnson Portable Compiler Theory
.]
and a system for typesetting mathematics.
.[
Kernighan Cherry typesetting system CACM
.]
.PP
The next several sections describe the
basic process of preparing a Yacc specification;
Section 1 describes the preparation of grammar rules,
Section 2 the preparation of the user supplied actions associated with these rules,
and Section 3 the preparation of lexical analyzers.
Section 4 describes the operation of the parser.
Section 5 discusses various reasons why Yacc may be unable to produce a
parser from a specification, and what to do about it.
Section 6 describes a simple mechanism for
handling operator precedences in arithmetic expressions.
Section 7 discusses error detection and recovery.
Section 8 discusses the operating environment and special features
of the parsers Yacc produces.
Section 9 gives some suggestions which should improve the
style and efficiency of the specifications.
Section 10 discusses some advanced topics, and Section 11 gives
acknowledgements.
Appendix A has a brief example, and Appendix B gives a
summary of the Yacc input syntax.
Appendix C gives an example using some of the more advanced
features of Yacc, and, finally,
Appendix D describes mechanisms and syntax
no longer actively supported, but
provided for historical continuity with older versions of Yacc.
@


1.2
log
@Remove original license disclaimer.
Add Caldera license.

Approved by:    David Taylor <davidt@@caldera.com>

Make roughly buildable under FreeBSD.

The results are not perfect: the original Makefile referred to a refer
file papers/Ind, which doesn't seem to have been kept, so the
references to other publications are missing.  In addition, the
pagination is not correct, with the result that some .DS/.DE blocks
leave large amounts of white space empty before them.  Possibly this
could be fixed by putting the (blank) footnotes at the end.

PR:   35345
Requested by:	Tony Finch <fanf@@dotat.at>
@
text
@d39 1
a39 1
.\" $FreeBSD$
@


1.2.24.1
log
@Switch importer
@
text
@d39 1
a39 1
.\" $FreeBSD: stable/7/share/doc/psd/15.yacc/ss0 96913 2002-05-19 05:14:02Z grog $
@


1.2.14.1
log
@Switch importer
@
text
@d39 1
a39 1
.\" $FreeBSD: stable/6/share/doc/psd/15.yacc/ss0 96913 2002-05-19 05:14:02Z grog $
@


1.2.42.1
log
@SVN rev 225736 on 2011-09-23 00:51:37Z by kensmith

Copy head to stable/9 as part of 9.0-RELEASE release cycle.

Approved by:	re (implicit)
@
text
@@


1.2.42.2
log
@## SVN ##
## SVN ## Exported commit - http://svnweb.freebsd.org/changeset/base/ 242902
## SVN ## CVS IS DEPRECATED: http://wiki.freebsd.org/CvsIsDeprecated
## SVN ##
## SVN ## ------------------------------------------------------------------------
## SVN ## r242902 | dteske | 2012-11-11 23:29:45 +0000 (Sun, 11 Nov 2012) | 10 lines
## SVN ##
## SVN ## Fix a regression introduced by SVN r211417 that saw the breakage of a feature
## SVN ## documented in usr.sbin/sysinstall/help/shortcuts.hlp (reproduced below):
## SVN ##
## SVN ## If /usr/sbin/sysinstall is linked to another filename, say
## SVN ## `/usr/local/bin/configPackages', then the basename will be used
## SVN ## as an implicit command name.
## SVN ##
## SVN ## Reviewed by:	adrian (co-mentor)
## SVN ## Approved by:	adrian (co-mentor)
## SVN ##
## SVN ## ------------------------------------------------------------------------
## SVN ##
@
text
@d39 1
a39 1
.\" $FreeBSD: stable/9/share/doc/psd/15.yacc/ss0 96913 2002-05-19 05:14:02Z grog $
@


1.2.42.1.4.1
log
@SVN rev 239080 on 2012-08-05 23:54:33Z by kensmith

Copy stable/9 to releng/9.1 as part of the 9.1-RELEASE release process.

Approved by:	re (implicit)
@
text
@@


1.2.42.1.4.2
log
@Switch importer
@
text
@d39 1
a39 1
.\" $FreeBSD: releng/9.1/share/doc/psd/15.yacc/ss0 96913 2002-05-19 05:14:02Z grog $
@


1.2.42.1.2.1
log
@SVN rev 227445 on 2011-11-11 04:20:22Z by kensmith

Copy stable/9 to releng/9.0 as part of the FreeBSD 9.0-RELEASE release
cycle.

Approved by:	re (implicit)
@
text
@@


1.2.42.1.2.2
log
@Switch importer
@
text
@d39 1
a39 1
.\" $FreeBSD: releng/9.0/share/doc/psd/15.yacc/ss0 96913 2002-05-19 05:14:02Z grog $
@


1.2.40.1
log
@SVN rev 216618 on 2010-12-21 17:10:29Z by kensmith

Copy stable/7 to releng/7.4 in preparation for FreeBSD-7.4 release.

Approved by:	re (implicit)
@
text
@@


1.2.40.2
log
@Switch importer
@
text
@d39 1
a39 1
.\" $FreeBSD: releng/7.4/share/doc/psd/15.yacc/ss0 96913 2002-05-19 05:14:02Z grog $
@


1.2.38.1
log
@SVN rev 203736 on 2010-02-10 00:26:20Z by kensmith

Copy stable/7 to releng/7.3 as part of the 7.3-RELEASE process.

Approved by:	re (implicit)
@
text
@@


1.2.36.1
log
@SVN rev 196045 on 2009-08-03 08:13:06Z by kensmith

Copy head to stable/8 as part of 8.0 Release cycle.

Approved by:	re (Implicit)
@
text
@@


1.2.36.2
log
@## SVN ##
## SVN ## Exported commit - http://svnweb.freebsd.org/changeset/base/ 242909
## SVN ## CVS IS DEPRECATED: http://wiki.freebsd.org/CvsIsDeprecated
## SVN ##
## SVN ## ------------------------------------------------------------------------
## SVN ## r242909 | dim | 2012-11-12 07:47:19 +0000 (Mon, 12 Nov 2012) | 20 lines
## SVN ##
## SVN ## MFC r242625:
## SVN ##
## SVN ## Remove duplicate const specifiers in many drivers (I hope I got all of
## SVN ## them, please let me know if not).  Most of these are of the form:
## SVN ##
## SVN ## static const struct bzzt_type {
## SVN ##       [...list of members...]
## SVN ## } const bzzt_devs[] = {
## SVN ##       [...list of initializers...]
## SVN ## };
## SVN ##
## SVN ## The second const is unnecessary, as arrays cannot be modified anyway,
## SVN ## and if the elements are const, the whole thing is const automatically
## SVN ## (e.g. it is placed in .rodata).
## SVN ##
## SVN ## I have verified this does not change the binary output of a full kernel
## SVN ## build (except for build timestamps embedded in the object files).
## SVN ##
## SVN ## Reviewed by:	yongari, marius
## SVN ##
## SVN ## ------------------------------------------------------------------------
## SVN ##
@
text
@d39 1
a39 1
.\" $FreeBSD: stable/8/share/doc/psd/15.yacc/ss0 96913 2002-05-19 05:14:02Z grog $
@


1.2.36.1.8.1
log
@SVN rev 232438 on 2012-03-03 06:15:13Z by kensmith

Copy stable/8 to releng/8.3 as part of 8.3-RELEASE release cycle.

Approved by:	re (implicit)
@
text
@@


1.2.36.1.8.2
log
@Switch importer
@
text
@d39 1
a39 1
.\" $FreeBSD: releng/8.3/share/doc/psd/15.yacc/ss0 96913 2002-05-19 05:14:02Z grog $
@


1.2.36.1.6.1
log
@SVN rev 216617 on 2010-12-21 17:09:25Z by kensmith

Copy stable/8 to releng/8.2 in preparation for FreeBSD-8.2 release.

Approved by:	re (implicit)
@
text
@@


1.2.36.1.4.1
log
@SVN rev 209145 on 2010-06-14 02:09:06Z by kensmith

Copy stable/8 to releng/8.1 in preparation for 8.1-RC1.

Approved by:	re (implicit)
@
text
@@


1.2.36.1.2.1
log
@SVN rev 198460 on 2009-10-25 01:10:29Z by kensmith

Copy stable/8 to releng/8.0 as part of 8.0-RELEASE release procedure.

Approved by:	re (implicit)
@
text
@@


1.2.34.1
log
@SVN rev 191087 on 2009-04-15 03:14:26Z by kensmith

Create releng/7.2 from stable/7 in preparation for 7.2-RELEASE.

Approved by:	re (implicit)
@
text
@@


1.2.32.1
log
@SVN rev 185281 on 2008-11-25 02:59:29Z by kensmith

Create releng/7.1 in preparation for moving into RC phase of 7.1 release
cycle.

Approved by:	re (implicit)
@
text
@@


1.2.30.1
log
@SVN rev 183531 on 2008-10-02 02:57:24Z by kensmith

Create releng/6.4 from stable/6 in preparation for 6.4-RC1.

Approved by:	re (implicit)
@
text
@@


1.1
log
@Initial checkin: 4.4BSD version.  These files need to be updated with
current license information and adapted to the FreeBSD build
environment before they will build.

Approved by:    David Taylor <davidt@@caldera.com>
@
text
@d1 35
a35 3
.\" This module is believed to contain source code proprietary to AT&T.
.\" Use and redistribution is subject to the Berkeley Software License
.\" Agreement and your Software Agreement with AT&T (Western Electric).
@

