-\documentclass[11pt]{article}
-\makeindex
-\usepackage{graphicx} % needed for including graphics e.g. EPS, PS
-\usepackage{listings} % for C syntax highlighting
+\documentclass{article}
+
+%%% PACKAGES
+\usepackage{geometry}
+\usepackage[utf8]{inputenc}
+\usepackage[parfill]{parskip}
+\usepackage{subfig}
+\usepackage{listings}
\usepackage{color}
-\usepackage{tipa}
-
-\definecolor{dkgreen}{rgb}{0,0.6,0}
-\definecolor{gray}{rgb}{0.5,0.5,0.5}
-\definecolor{mauve}{rgb}{0.58,0,0.82}
-
-% set listings colors
-\lstset{ %
- backgroundcolor=\color{white}, % choose the background color; you must add \usepackage{color} or \usepackage{xcolor}
- basicstyle=\footnotesize, % the size of the fonts that are used for the code
- breakatwhitespace=false, % sets if automatic breaks should only happen at whitespace
- breaklines=true, % sets automatic line breaking
- captionpos=b, % sets the caption-position to bottom
- commentstyle=\color{dkgreen}, % comment style
- deletekeywords={...}, % if you want to delete keywords from the given language
- escapeinside={\%*}{*)}, % if you want to add LaTeX within your code
- keywordstyle=\color{blue}, % keyword style
- language=C, % the language of the code
- morekeywords={entity,local}, % if you want to add more keywords to the set
- numbers=left, % where to put the line-numbers; possible values are (none, left, right)
- numbersep=5pt, % how far the line-numbers are from the code
- numberstyle=\tiny\color{gray}, % the style that is used for the line-numbers
- rulecolor=\color{black}, % if not set, the frame-color may be changed on line-breaks within not-black text (e.g. comments (green here))
- showspaces=false, % show spaces everywhere adding particular underscores; it overrides 'showstringspaces'
- showstringspaces=false, % underline spaces within strings only
- showtabs=false, % show tabs within strings adding particular underscores
- stepnumber=1, % the step between two line-numbers. If it's 1, each line will be numbered
- stringstyle=\color{mauve}, % string literal style
- tabsize=2, % sets default tabsize to 2 spaces
- title=\lstname % show the filename of files included with \lstinputlisting; also try caption instead of title
+\usepackage{sectsty}
+
+%%% GEOMETRY FOR DOCUMENT
+\geometry{a4paper}
+
+%%% HEADERS/FOOTERS APPEARANCE
+\usepackage{fancyhdr} % This should be set AFTER setting up the page geometry
+\pagestyle{fancy} % options: empty , plain , fancy
+\renewcommand{\headrulewidth}{0pt} % customise the layout...
+\lhead{}\chead{}\rhead{}
+\lfoot{}\cfoot{\thepage}\rfoot{}
+
+%%% SECTION TITLE APPEARANCE
+\allsectionsfont{\sffamily\mdseries\upshape} % (See the fntguide.pdf for font help)
+
+%%% ToC APPEARANCE
+\usepackage[nottoc,notlof,notlot]{tocbibind} % Put the bibliography in the ToC
+\usepackage[titles,subfigure]{tocloft} % Alter the style of the Table of Contents
+\renewcommand{\cftsecfont}{\rmfamily\mdseries\upshape}
+\renewcommand{\cftsecpagefont}{\rmfamily\mdseries\upshape} % No bold!
+
+%%% listing language definitions
+%%% BNF for now, QuakeC will be later
+\definecolor{keyword1}{RGB}{0,102,153}
+\definecolor{keyword2}{RGB}{0,153,102}
+\definecolor{keyword3}{RGB}{0,153,255}
+\definecolor{comment}{RGB}{204,0,0}
+\definecolor{function}{RGB}{153,102,255}
+\definecolor{digit}{RGB}{255,0,0}
+\definecolor{string}{RGB}{255,0,204}
+\definecolor{rule}{RGB}{192,192,192}
+\definecolor{back}{RGB}{250,250,250}
+
+\lstdefinelanguage{bnf}{
+ keywordstyle={\color{keyword2}\bfseries},
+ keywords={},
+ otherkeywords={::=,|},
+ morecomment=[s][\color{comment}]{(*}{*)},
+ stringstyle=\color{string},
+ morestring=[b]",
+ morestring=[b]',
+ morestring=[b]/,
+ showstringspaces=false,
+ frame=none,
+ rulecolor=\color{rule},
+ backgroundcolor=\color{back}
}
-\topmargin -1.5cm % read Lamport p.163
-\oddsidemargin -0.04cm % read Lamport p.163
-\evensidemargin -0.04cm
-
-\textwidth 16.59cm
-\textheight 21.94cm
-\parskip 7.2pt % spacing between paragraphs
-\renewcommand{\baselinestretch}{1.5} % 1.5 spacing between lines
-\parindent 0pt % leading space for paragraphs
-\title{The GMQCC Quake C Programming Language}
-\author{Dale Weiler, Wolfgang Bullimer}
-
-% subscript and superscript in text mode require
-% strange uses of math expression scripting, which
-% is unusable, these macros implement it using math
-% expressions, and reimplement ^ and _ to work in
-% text mode :-)
-\makeatletter
-\newcommand\textsubscript[1]{\@textsubscript{\selectfont#1}}
-\def\@textsubscript#1{{\m@th\ensuremath{_{\mbox{\fontsize\sf@size\z@#1}}}}}
-\newcommand\textbothscript[2]{%
- \@textbothscript{\selectfont#1}{\selectfont#2}}
-\def\@textbothscript#1#2{%
- {\m@th\ensuremath{%
- ^{\mbox{\fontsize\sf@size\z@#1}}%
- _{\mbox{\fontsize\sf@size\z@#2}}}}}
-\def\@super{^}\def\@sub{_}
-
-\catcode`^\active\catcode`_\active
-\def\@super@sub#1_#2{\textbothscript{#1}{#2}}
-\def\@sub@super#1^#2{\textbothscript{#2}{#1}}
-\def\@@super#1{\@ifnextchar_{\@super@sub{#1}}{\textsuperscript{#1}}}
-\def\@@sub#1{\@ifnextchar^{\@sub@super{#1}}{\textsubscript{#1}}}
-\def^{\let\@next\relax\ifmmode\@super\else\let\@next\@@super\fi\@next}
-\def_{\let\@next\relax\ifmmode\@sub\else\let\@next\@@sub\fi\@next}
-\makeatother
-
-% set standard paper sizes
-\setlength{\paperheight}{11in}
-\setlength{\paperwidth}{8.5in}
-
+%% Title Information %%
+\title{The GMQCC QuakeC Programming Language}
+\author{Dale Weiler}
+\date{\today}
+
\begin{document}
+
+%% Title Page %%
\maketitle
-\pagebreak
+\thispagestyle{empty}
+\raggedright
+\abstract
+This document specifies the form and establishes the interpretation of programs written in
+the GMQCC QuakeC programming language variant (refereed simply as QuakeC throughout this
+document). It specifies:
+\begin{itemize}
+ \item the representation of QuakeC programs;
+ \item the syntax and constraints of the QuakeC language;
+ \item the semantic rules for interpreting QuakeC programs;
+ \item the representation of input data to be processes by QuakeC programs;
+ \item the representation of output data produced by QuakeC programs;
+ \item the restrictions and limits imposed by a conforming implementation of QuakeC.
+\end{itemize}
+This document does not specify
+\begin{itemize}
+ \item the mechanism by which QuakeC programs are transformed for use by a data-
+ processing system;
+ \item the mechanism by which QuakeC programs are invoked for use by a data-processing
+ system;
+ \item the mechanism by which input data are transformed for use by a QuakeC program;
+ \item the size or complexity of a program and its data that will exceed the capacity
+ of any specific data-processing system or the capacity of a particular
+ execution environment;
+ \item all minimal requirements of a data-processing system that is capable of
+ supporting a conforming implementation.
+\end{itemize}
+
+%% Table Of Contents %%
+\newpage
+\thispagestyle{empty}
\tableofcontents
-\pagebreak
-\section{Introduction}
-With the introduction of improvements of existing runtime environments, new features may be added to this specification. Subclauses in the language warn implementors and programmers of usages which, though valid in themselfs, may conflict with future additions.
-
-This specification is divided into three major subjects:
-\begin{enumerate}
- \item preliminary elements
- \item the characteristics of environments that translate and execute QuakeC programs
- \item the languages syntax, constraints, and semantics
-\end{enumerate}
-
-Examples are provided to illustrate possible forms of the constructions described, to better facilitate the reader.
-
-\section{Scope}
-This specification only specifies the form and establishes the interpretation of programs written in the GMQCC QuakeC programming language variant. It specifies:
-\begin{enumerate}
- \item The representation of Quake C programs;
- \item The syntax and constraints of the Quake C language;
- \item The semantic rules for interpreting Quake C programs;
- \item The representation of input data to be processed by Quake C programs;
- \item The restrictions and limits imposed by a conforming implementation of Quake C.
-\end{enumerate}
-This specification does not specify
-\begin{enumerate}
- \item The process in which Quake C programs are transformed for use by a data-processing system;
- \item The process in which Quake C programs are invoked for use by a data-processing system;
- \item The process in which input data is transformed for use by a Quake C program;
- \item The process in which output data is transformed after being produces by a Quake C program;
- \item The size of complexity involved with a Quake C program and its data that will exceed the capacity of any specific data-processing system or the capacity of a particular processor;
- \item The minimal requirements of a data-processing system which is capable of supporting a conforming implementation.
-\end{enumerate}
-These details are decided upon by the environment designer (usually the engine developer). The details are as such subjected to implementation-defined behavior.
-
-\section{Terms and definitions}
+\newpage
+
+%% Begin Contents %%
+\raggedright % No weird TEX spacing on lines to fill page
+
+%% -> Terms, definitions, and symbols %%
+\section{Terms, definitions, and symbols}
\subsection*{argument}
-The expression in a comma-separated list bounded by parentheses in a function call expression, or a sequence of preprocessing tokens in a comma-separated list bounded by parentheses in a function-like macro invocation.
+Expression in the comma-separated list bounded by the parentheses in a function call
+expression, or a sequence of preprocessing tokens in the comma-separated list bounded
+by the parentheses in a function-like macro invocation.
+
\subsection*{behavior}
-The external appearance or action of an expression, statement, etc
+External appearance or action
+
\subsection*{implementation-defined behavior}
-Unspecified behavior where each implementation decides how the choice is made.
+Unspecified behavior where each implementation documents how the choice is made.
+
+\subsection*{undefined behavior}
+Behavior, upon use of a non-portable or erroneous program construct or of erroneous data,
+for which this document imposes no actual requirements.
+
\subsection*{unspecified behavior}
-Use of an unspecified value, or other behavior where this specification provides two or more possibilities and imposes no further requirements on which is chosen in any instance (e.g. Thus any ambiguity is considered unspecified behavior).
+Use of an unspecified value, or other behavior where this document provides two or more
+possibilities and imposes no further requirements on which is chosen in any instance.
+
\subsection*{constraint}
-A restriction, either syntactically or semantically, by which the exposition of various language elements is to be interpreted.
-\subsection*{implementation}
-Particular set of software, running in a particular translation environment under particular control options, that performs translations of programs for, and supports execution of functions in, a particular execution environment.
+Restriction, either syntactic or semantic, by which the exposition of language elements
+is to be interpreted.
+
+\subsection*{diagnostic message}
+Message belonging to an implementation-defined subset of the implementation's message
+output.
+
\subsection*{object}
-A region of data storage in the execution environment, the contents of which are capable of representing values.
+Region of data storage in the execution environment, the contents of which can represent
+values.
+
\subsection*{parameter}
-An object declared as part of a function declaration that acquires a value on entry to the function, or an identifier from the comma-separated list bounded by parentheses immediately following the macro name in a function-like macro definition.
+Object declare as part of a function declaration or definition that acquires a value on
+entry to the function, or an identifier from the comma-separated list bounded by the
+parentheses immediately following the macro name in a function-like macro definition.
+
+\subsection*{recommended practice}
+Specification that is strongly recommended as being in keeping with the intent of this
+document, but that may be impractical for some implementations.
+
\subsection*{value}
-The precise meaning of the contents of an object when interpreted as having a specific type.
+Precise meaning of the contents of an object when interpreted as having a specific type.
+
\subsection*{implementation-defined value}
-An unspecified value where each implementation decides how the choice is made.
+Unspecified value where each implementation documents how the choice is made.
+
\subsection*{unspecified value}
-A valid value of the relevant type where this specification imposes no requirements on which value is chosen in any instance.
+Valid value of the relevant type where this document imposes no requirements on which
+value is chosen in any instance.
+%% -> Conformance %%
\section{Conformance}
-In this specification, "shall" is to be interpreted as a requirement on an implementation or on a program; conversely, "shall not" is to be interpreted as a prohibition on the implementation or on a program.
-
-A conforming program is one that is acceptable to a conforming implementation.
-
-An implementation shall be accompanied by a document that defines all implementation-defined characteristic and extensions.
-
-\section{Enviroment}
+In this document, "shall" is to be interpreted as a requirement on an implementation
+or on a program; conversely, "shall not" is to be interpreted as a prohibition. \\
+If a "shall" or "shall not" requirement that appears outside of a constraint is violated,
+the behavior is undefined. Undefined behavior is otherwise indicated in this document by
+the words "undefined behavior" or by the omission of any explicit definition of behavior.
+There is no difference in emphasis among these three; they all describe "behavior that is
+undefined".
+
+%% -> Enviroment %%
+\section{Environment}
+An implementation that translates QuakeC source files and executes QuakeC programs in two
+data processing-system environments, which will be called the translation environment and
+the execution environment in this document. Their characteristics define and constrain the
+results of executing QuakeC programs constructed according to the syntactic and semantic
+rules for conforming implementations.
\subsection{Conceptual models}
\subsubsection{Translation environment}
-\paragraph{Program structure}
-A Quake C program need not all be translated at the same time. The text of the program is kept in units called source files. All source files become concatenated, less any source lines skipped by any of the conditional inclusion preprocessing directives. The final concatenation becomes the program structure.
-
-\paragraph{Translation phases}
-\begin{enumerate}
- \item Physical source file characters are mapped to the source character set (introducing new-line characters for end-of-line indicators) if necessary. Trigraph and Digraph sequences are replaced by corresponding single-character internal representations.
- \item The source file is decomposed into preprocessing tokens and sequences of white-space characters (including comments).
- \item Preprocessing directives are executed and macro invocations expanded recursively.
- \item Each escape sequence in character constants and string literals is converted to a member of the execution character set.
- \item Adjacent character string literal tokens are concatenated.
- \item White-space characters separating tokens are no longer sufficient. The resulting tokens are syntactically and semantically analyzed and translated.
-\end{enumerate}
-
-\paragraph{Diagnostics}
-A conforming implementation shall produce at least one diagnostic message (identified in an implementation-defined manner) if a program structure contains a violation of any syntax rule or constraint, even if the behavior is explicitly specifies as being undefined or implementation-defined. diagnostic messages need not be produces in other circumstances.
-\begin{small}
-EXAMPLE
-\end{small}
-\begin{lstlisting}[language=C]
- string i;
- float i;
-\end{lstlisting}
-The following example should produce a diagnostic for the program structure.
-
+\paragraph*{Translation steps}
+The precedence among the syntax rules of translation is specified by the following steps
+\begin{itemize}
+ \item Physical source file characters are mapped, in an implementation-defined manner,
+ to the source character set (introducing new-line characters for end-of-line
+ indicators) if necessary. Trigraph and digraph sequences are replaced by their
+ corresponding single-character internal representations.
+ \item The source file is decomposed into preprocessing tokens and sequences of white-
+ space characters (including comments). A source file shall not end in a partial
+ preprocessing token or in a partial comment. Each comment is replaced by one
+ space character. New-line characters are retained. Whether each nonempty
+ sequences of white-space characters other than new-line is retained or replaced
+ by one space character is implementation-defined.
+ \item Preprocessing directives are executed, macro invocations are expanded
+ recursively. A \#include preprocessing directive causes the named header or
+ source file to be processes from step one through step three, recursively. All
+ preprocessing directives are then deleted.
+ \item Each source character set member and escape sequence in character constants and
+ string literals is converted to the corresponding member of the execution
+ character set; if there is no corresponding member, it is converted to an
+ implementation-defined member other than the null character.
+ \item Adjacent string literal tokens are concatenated.
+ \item White-space characters seperating tokens are no longer significant. Each
+ preprocessing token is converted into a token. The resulting tokens are then
+ syntactically and semantically analyzed and translated.
+\end{itemize}
+\subparagraph*{Footnotes}
+Implementations shall behave as if these separate steps occur, even though many are likely
+to be folded together in practice. Source files need not be stored as file, nor need there
+be any one-to-one correspondence between these items and any external representation. The
+description is conceptual only, and does not specify any particular implementation.
+
+\paragraph*{Diagnostics}
+A conforming implementation shall produce at least on diagnostic message(identified in an
+implementation-defined manner) if a source file contains a violation of any syntax rule or
+constraint, even if the behavior is also explicitly specified as undefined or
+implementation-defined. Diagnostic messages need not be produced in other circumstances.
+
+%% ->-> Execution environments %%
+\subsubsection{Execution environments}
+Two execution environments are defined
+
+%% -> Language %%
\section{Language}
\subsection{Notation}
-In the syntax notation used in this clause, syntactic categories (non-terminals) are indicated by italic type, and literal words and character set members (terminals) by bold type. A colon (:) following a non-terminal introduces its definition. Alternative definitions are listed on corresponding separate lines, except when prefaced by words "one of". An optional symbol is indicated by a subscript "opt", so that\\
-\{ expression _{opt} \}\\
-indicates an optional expression closed in braces. When syntactic categories are refereed to in the main text, they are not italicized and words are separated by spaces instead of hyphens.
-
+The syntax notation used in this document is that of a BNF specification. A set of
+derivation rules, often written as:
+\begin{lstlisting}[language=bnf]
+ symbol ::= expression
+\end{lstlisting}
+Where symbol is a nonterminal, and the expression consists of one or more sequences of
+symbols; more sequences are separated by a vertical bar \textbar, indicating a choice,
+the whole being a possible substitution for the symbol on the left. Symbols that never
+appear on the left side are terminals.
+\linebreak
+This document defines language syntax throughout it's way at defining language
+constructs If you're interested in a summary of the language syntax, one is given in
+annex A.
+
+%% -> Concepts %%
\subsection{Concepts}
+%% ->-> Scopes of identifiers %%
\subsubsection{Scopes of identifiers}
-An identifier can denote an object; a function; a tag or member of an entity, or enumeration; a typedef name; a label name; a macro name; or a macro parameter. The same identifier can denote different entities at different points in the program. A member of an enumeration is called an enumeration constant. Macro names and macro parameters are not considered further here, because prior to the semantic phase of program translation any occurrences of macro names in the source file are replaced by the preprocessing token sequences that constitute their macro definitions.
-
-For each different entity that an identifier designates, the identifier is visible (i.e., can be used) only within a region of program text called its scope. Different entities designated by the same identifier either have different scopes, or are in different name spaces. There are four kinds of scopes: function, global, block and function prototype. (A function prototype is a declaration of a function that declares the types of its parameters.)
-
-A label name is the only kind of identifier that has function scope. It can be used (in a goto statement) anywhere in the function in which it appears, and is declared implicitly by it's syntactic appearance (prefixed by a : and a statement).
-
-Every other identifier has scoped determined by the placement of its declaration (in a declarator or type specifier). If the declarator or type specifier that declares the identifier appears outside of any block or list of parameters, the identifier has global scope, which terminates at the end of the program structure. If the declarator or type specifier that declares the identifier appears inside a block or within the list of parameter declarations in a function definition, the identifier has block scope, which terminates at the end of the associated block. If the declarator or type specifier that declares the identifier appears within the list of parameter declarations in a function prototype (not part of a function definition), the identifier has function prototype scope, which terminates at the end of the function declarator. If an identifier designates two different entities in the same name space, the scopes might overlap. If so, the scope of one entity (the inner scope) will be a strict subset of the scope of the other entity (the outer scope). Within the inner scope, the identifier designates the entity declared in the inner scope; the entity declared in the outer scope is hidden (and is not visible) within the inner scope.
-
-Unless explicitly stated otherwise, where this specification uses the term "identifier" to refer to some entity (as opposed to the syntactic construct), it refers to the entity in the relevant name space whose declaration is visible at the point the identifier occurs.
-
-Unless explicitly stated otherwise, where this specification uses the term "entity", is not to be ambiguous with the entity type, but considered a semantic construct.
-
-Two identifiers have the same scope if and only if their scopes terminate at the same point.
-
-Enumeration tags have scope that begins just after the appearance of the tag in a type specifier that declares the tag. Each enumeration constant has scope that begins just after the appearance of its defining enumerator in an enumeration list. Any other identifier has scope that begins just after the completion of its declarator.
-
+An identifier can denote an object; a function, or enumeration; a label name; a macro
+name; or a macro parameter. The same identifier can denote difference items at different
+point in the program. A member of an enumeration is called an enumeration constant.
+Macro names and macro parameters are not considered further here, because prior to the
+semantic phase of program translation any occurrences of macro names in the source file
+are replaced by the preprocessing token sequences that constitute their macro definitions.
+\linebreak
+
+For each different item that an identifier designates, the identifier is visible (i.e,
+can be used) only within a region of program text called its scope. Different items
+designated by the same identifier either have different scopes, or are in different name
+spaces. There are four kinds of scopes: function, file, block and function prototype.
+(A function prototype is a declaration of a function that declares the types of its
+parameters.)
+\linebreak
+
+A label name is the only kind of identifier that has function scope. It can be used (in
+a goto statement) anywhere in the function in which it appears, and is declared
+implicitly by its syntactic appearance (prefixed by a : and a statement).
+\linebreak
+
+Every other identifier has scope determined by the placement of its declaration (in a
+declarator or type specifier). If the declarator or types specifier that declares the
+identifier appears outside any block or list of parameters, the identifier has file
+scope, which terminates at the end of the file. If the declartor or type specifier that
+declares the identifier appears inside a block or within the list of parameter
+declarations in a function definition, the identifier has block scope, which terminates
+at the end of the associated block. If the declarator or type specifier that declares
+the identifier appears within the list of parameter declarations in a function prototype
+(not part of a function definition), the identifier has function prototype scope, which
+terminates at the end of the function declarator. If an identifier designates two
+different items in the same name space, the scopes might overlap. If so, the scope of
+one item (the inner scope) will be a strict subset of the scope of the other item (the
+outer scope). Within the inner scope, the identifier designates the item declared in the
+inner scope; the item declared in the outer scope is hidden (and not visible) within
+the inner scope.
+\linebreak
+
+Unless explicitly stated otherwise, where this document uses the term "identifier" to
+refer to some item (as opposed to the syntactic construct), it refers to the item in the
+relevant name space whose declaration is visible at the point the identifier occurs.
+\linebreak
+
+Two identifiers have the same scope it and only if their scopes terminate at the same
+point.
+\linebreak
+
+Each enumeration constant has scope that begins just after the appearance of its defining
+enumerator in an enumerator list. Any other identifier has scope that begins just after
+the completion of its declarator.
+
+%% ->-> Name spaces of identifiers %%
\subsubsection{Name spaces of identifiers}
-If more than one declaration of a particular identifier is visible at any point in the program structure, the syntactic context disambiguates uses that refer to different entities. Thus, there are separate name spaces for various categories of identifiers, as follows:
-\begin{enumerate}
- \item label names (disambiguated by the syntax of the label declaration and use);
- \item the tags of enumerations
- \item all other identifiers, called ordinary identifiers (declared in ordinary declarators or as enumeration constants).
-\end{enumerate}
-
+If more than one declaration of a particular identifier is visible at any point in a
+source file, the syntactic context disambiguates uses that refer to different items.
+Thus, there are separate name spaces for various categories of identifiers, as follows:
+\linebreak
+\begin{itemize}
+ \item Label names (disambiguated by the syntax of the lbvel declaration and use);
+ \item Enumerations (disambiguated by following the keyword enum);
+ \item All other identifiers, called ordinary identifiers (declared in ordinary
+ declarators or as enumeration constants).
+\end{itemize}
+
+%% ->-> Types %%
\subsubsection{Types}
-The meaning of a value stored in an object or returned by a function is determined by the type of the expression used to access it. (An identifier declared to be an object is the simplest such expression; the type is specified in the declaration of the identifier.) Types are partitioned into object types(types that fully describe object) and function types(types that describe functions).
-
-An object declares as type bool is large enough to store the values 0 and 1.
-
-An object declared as type char is large enough to store any member of the basic execution character set. If a member of the basic execution character set is stored in a char object, its value is guaranteed to be nonnegative. If any other character is stored in a char, the resulting value is implemented-defined.
-
-An object declared as type string is large enough to store any length string-literal composed of any length chars, and as such follows the same rules as an object declared as type char.
-
-The void type comprises an empty set of values; it is an incomplete type that cannot be completed.
-
-The float and vector type .. TODO
-
-An enumeration comprises a set of named integer constant values. Each enumeration constitutes a different enumerated type.
-
-\subsubsection{Compatible type and composite type}
-Two types have compatibility if their types are the same.
+The meaning of a value stored in an object returned by a function is determined by the
+type of the expression used to access it. (An identifier declared to be an object is the simplest
+such expression; the type is specified in the declaration of the identifier.) Types are
+partitioned into object types (types that fully describe objects), function types(types
+that describe functions), and incomplete types(types that describe objects but lack
+information).
+\linebreak
+
+An object declared type bool is large enough to store the values 0 and 1.
+\linebreak
+
+An object declared type float is a real type; An object declared type vector is a
+comprised set of three floats that respectively represent the \underline{x,y,z}
+components of a three-dimensional vector.
+\linebreak
+
+An enumeration comprises a set of named integer constant values. Each distinct
+enumeration constitutes a different enumerated type.
+\linebreak
+
+Enumeration types and float are collectively called arithmetic types. Each arithmetic
+type belongs to one type domain.
+\linebreak
+
+The void type comprises an empty set of values; it is an incomplete type that cannot be
+completed.
+\linebreak
+
+A number of derived types can be constructed from the object, function and incomplete
+types, as follows:
+\linebreak
+
+\begin{itemize}
+ \item An array type describes a contiguously allocated nonempty set of objects with a
+ particular object types, called the element type. Array types are characterized
+ by their element type and by the number of elements in the array. An array type
+ is said to be derived from its element type, and if its element is type T, the
+ array type is sometimes called "array of T". The construction of an array type
+ from an element type is called "array type derivation".
+ \item A function type described a function with a specified return type. A function
+ type is characterized by its return type and the number and types of its
+ parameters. A function type is said to be derived from its return type, and if
+ its return type is T, the function type is sometimes called "function returning
+ T". The construction of a function type from a return type is called "function
+ type derivation".
+\end{itemize}
+
+\
+
+Arithmetic types are collectively called scalar types. Arrays and vectors are
+collectively called aggregate types.
+\linebreak
+
+An array of unknown size is an incomplete type. It is completed, for an identifier of
+that byte, by specifying the size in a later declaration. Arrays are required to have
+known constant size.
+\linebreak
+
+A type is characterized by its type category, which is either the outermost derivation
+of a derived type (as noted above in the construction of derived types), or the type
+itself if the type consists of no derived types.
+\linebreak
+
+Any type so far mentioned is an unqualified type. Each unqualified type has several
+qualified version of its type, corresponding to the combinations of one, two, or all
+two of const and volatile qualifiers. The qualified or unqualified versions of a type
+are distinct types that belong to the same type category and have the same representation.
+A derived type is not qualified by the qualifiers (if any) of the type from which it
+is derived.
+\linebreak
+
+%% ->-> Compatible types and composite type %%
+\subsubsection{Compatible types and composite type}
+Two types have compatible type if their types are the same.
+\linebreak
+
+All declarations that refer to the same object or function shall have compatible type;
+otherwise the behavior is undefined.
+\linebreak
+
+A composite type can be constructed from two types that are compatible; it is a type that
+is compatible with both of the two types and satisfies the following conditions:
+\begin{itemize}
+ \item If one type is an array, the composite type is an array of that size.
+ \item If only one type is a function type with a parameter type list(a function
+ prototype), the composite type is a function prototype with the parameter type
+ list.
+ \item If both types are function types with parameter type lists, the type of each
+ parameter in the composite parameter type list is the composite type of the
+ corresponding parameters.
+\end{itemize}
+These rules apply recursively to types from which the twp types are derived.
+\linebreak
+
+%% ->Conversions %%
+\subsection{Conversions}
+Several operators convert operand values from one type to another automatically. This
+sub-clause specified the result required from such an implicit conversion.
+\linebreak
-All declarations that refer to the same object or function shall have compatibility; otherwise, the behavior is undefined.
+Conversion from an operand value to a compatible type causes no change to the value or
+the representation.
+\linebreak
-A composite type can be constructed from two types that are compatible; it is a type that is compatible with both of the two types and satisfies the following conditions:
-\begin{enumerate}
- \item If one type is a function type with a paramater type list (function prototype), the composite type is a function prototype with the parameter type list.
- \item If both types are function types with parameter type lists, the type of each parameter in the composite parameter type list is the composite type of the corresponding parameters.
-\end{enumerate}
+%% ->->Aritmetic operands %%
+\subsubsection{Arithmetic operands}
+\paragraph*{Boolean type}
+When any scalar value is converted to bool, the result is 0 if the value compares equal
+to 0; otherwise the result is 1.
-\subsection{Conversions}
+%% ->->Other operands %%
\subsubsection{Other operands}
-\paragraph{Lvalues, arrays, and function designators}
-An lvalue is an expression with an object type or an incomplete type other than void; if an lvalue does not designate an object when it is evaluated, the behavior is undefined. When an object is said to have a particular type, the type is specified by the lvalue used to designated said object. A modifiable lvalue is an lvalue that does not have an array type, does not have a const-qualified type and does not have an incomplete type.
+\paragraph{Lvalues, arrays and function designators}
+An lvalue is an expression with an object type or an incomplete type other than void;
+if an lvalue does not designate an object when it is evaluated, the behavior is undefined.
+When an object is said to have a particular type, the type is specified by the lvalue
+used to designate the object. A modifiable lvalue is an lvalue that does not have an
+array type, does not have an incomplete type, does not have a const-qualified type.
+\linebreak
+
+Except when it is the operand of the unary \& operator, the ++ operator, the -- operator,
+or the left operand of the . operator or an assignment operator, an lvalue that does not
+have array type is converted to the value stored in the designated object (and is no
+longer an lvalue). If the lvalue has qualified type, the value has the unqualified
+version of the type of the lvalue; otherwise, the value has the type of the lvalue. If
+the lvalue has an incomplete type and does not have array type, the behavior is undefined.
+\linebreak
+
+A function designator is an expression that has function type.
+\linebreak
+
+\paragraph*{void}
+The (nonexistent) value of a void expression (an expression that has type void) shall not
+be used in any way, and implicit conversions (except to void) shall not be applied to
+such an expression. If an expression of any other type is evaluated as a void expression
+, its value or designator is discarded. (A void expression is only evaluated for its
+side effects.)
+\pagebreak
-A function designator is an expression that has function type. A function designator with type "function returning type" is converted to an expression that has type "pointer to function returning type".
+\subsection{Lexical elements}
+\paragraph*{Syntax}
+\begin{lstlisting}[language=bnf]
+token ::= keyword | identifier
+ | constant | string-literal
+ | punctuator
+
+preprocessing-token := header-name | identifier
+ | pp-number | string-literal
+ | punctuator
+\end{lstlisting}
+\paragraph*{Constraints}
+Each preprocessing token that is converted to a token shall have the lexical form of a
+keyword, an identifier, a constant, a string literal, or a punctuator.
-\paragraph{void}
-The (nonexistent) value of a void expression (an expression that has type void) shall not be used in any way, and implicit or explicit conversions (except to void) shall not be applied to any such expression. If an expression of a type not void is evaluated as a void expression, its value or designator shall be discarded. (A void expression is evaluated only for its side effects.)
+\paragraph*{Semantics}
+TODO
-\subsection{Lexical elements}
+%% ->-> Keywords %%
\subsubsection{Keywords}
-\begin{tabular} { l l l l l }
- for & do & while & if & else \\
- local & return & const & switch & case \\
- default & struct & union & break & continue \\
- typedef & goto & namespace \\
-\end{tabular}
+\paragraph*{Syntax}
+\begin{lstlisting}[language=bnf]
+keyword ::= enum | break
+ | return | void
+ | case | float
+ | volatile | for
+ | while | const
+ | goto | bool
+ | continue | if
+ | static | default
+ | inline | do
+ | switch | else
+ | vector | entity
+\end{lstlisting}
+\paragraph*{Semantics}
+The above tokens (case sensitive) are reserved (in translation step seven and eight) for
+use as keywords, and shall not be used otherwise.
+%% ->->Identifiers %%
\subsubsection{Identifiers}
-\paragraph*{identifier}
-\begin{tabular} { l }
- identifier-nondigit \\
- identifier identifier-nondigit \\
- identifier-digit \\
-\end{tabular}
-
-\paragraph*{identifier-nondigit}
-\begin{tabular} { l }
- nondigit \\
- other implementation-defined characters \\
-\end{tabular}
-
-\paragraph*{nondigit}
-\begin{tabular}{ c c c c c c c c c c c c c c c c c c c c }
- \_ & a & b & c & d & e & f & g & h & i & j & k & l & m & n & o & p & q & r & s \\
- t & u & v & w & y & z & A & B & C & D & E & F & G & H & I & J & K & L & M & N \\
- O & P & Q & R & S & T & U & V & W & X & Y & Z \\
-\end{tabular}
-
-\paragraph*{digit}
-\begin{tabular}{c c c c c c c c c c c }
- 0 & 1 & 2 & 3 & 4 & 5 & 6 & 7 & 8 & 9 \\
-\end{tabular}
-
-\paragraph*{hex-quad}
-\begin{tabular} { l }
- hexadecimal-digit hexadecimal-digit \\
-\end{tabular}
+\paragraph*{Syntax}
+\begin{lstlisting}[language=bnf]
+identifier ::= nondigit
+ | identifier nondigit
+ | identifier digit
+
+nondigit ::= _ | a | b | c | d | e | f | g | h | i
+ | j | k | l | m | n | o | p | q | r | s
+ | t | u | v | w | x | y | z | A | B | C
+ | D | E | F | G | H | I | J | K | L | M
+ | N | P | Q | R | S | T | U | V | W | X
+ | Y | Z
+
+digit ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
+\end{lstlisting}
+%% ->->Constants %%
\subsubsection{Constants}
-\label{sec:constants}
-\paragraph*{constant}
-\begin{tabular} { l }
- integer-constant \\
- floating-constant \\
- enumeration-constant \\
- character-constant \\
- vector-constant \\
-\end{tabular}
-
-\paragraph*{integer-constant}
-\begin{tabular} { l }
- decimal-constant \\
- octal-constant \\
- hexadecimal-constant \\
-\end{tabular}
-
-\paragraph*{decimal-constant}
-\begin{tabular} { l }
- nonzero-digit \\
- decimal-constant digit \\
-\end{tabular}
-
-\paragraph*{octal-constant}
-\begin{tabular} { l }
- 0 \\
- octal-constant octal-digit
-\end{tabular}
-
-\paragraph*{hexadecimal-constant}
-\begin{tabular} { l }
- hexadecimal-prefix hexadecimal-digit \\
- hexadecimal-constant hexadecimal-digit \\
-\end{tabular}
-
-\paragraph*{hexadecimal-prefix}
-\begin{tabular} { c c }
- 0x & 0X \\
-\end{tabular}
-
-\paragraph*{nonzero-digit}
-\begin{tabular} { c c c c c c c c c }
- 1 & 2 & 3 & 4 & 5 & 6 & 7 & 8 & 9 \\
-\end{tabular}
-
-\paragraph*{octal-digit}
-\begin{tabular}{ c c c c c c c c c }
- 0 & 1 & 2 & 3 & 4 & 5 & 6 & 7 \\
-\end{tabular}
-
-\paragraph*{hexadecimal-digit}
-\begin{tabular}{ c c c c c c c c c c c c c c c c }
- 0 & 1 & 2 & 3 & 4 & 5 & 6 & 7 & 8 & 9 & A & B & C & D & E & F \\
-\end{tabular}
-
-\paragraph*{floating-constant}
-\begin{tabular} { l }
- decimal-floating-constant \\
- hexadecimal-floating-constant \\
-\end{tabular}
-
-\subsubsection{String Literals}
-\paragraph*{string-literal}
-\begin{tabular} { l }
- " s-char-sequence _{opt} " \\
- \_(" s-char-sequence _{opt} ") \\
-\end{tabular}
-
-\subsubsection*{s-char-sequence}
-\begin{tabular} { l }
- s-char \\
- s-char-sequence s-char \\
-\end{tabular}
-
-\subsubsection*{s-char}
-\begin{tabular} { l }
- any member of the source character set except double-quote, backslash, or new-line characters \\
- escape-sequence \\
-\end{tabular}
-
-\subsubsection{Header names}
-\paragraph*{header-name}
-\begin{tabular} { l }
- < h-char-sequence > \\
- " q-char-sequence " \\
-\end{tabular}
-
-\subsubsection*{h-char-sequence}
-\begin{tabular} { l }
- h-char \\
- h-char-sequence h-char \\
-\end{tabular}
-
-\subsubsection*{h-char}
-\begin{tabular} { l }
- any member of the source character set except the new-line and > character \\
-\end{tabular}
-
-\subsubsection*{q-char-sequence}
-\begin{tabular} { l }
- q-char \\
- q-char-sequence q-char \\
-\end{tabular}
-
-\subsubsection*{q-char}
-\begin{tabular} { l }
- any member of the source character set except the new-line and " character \\
-\end{tabular}
-
-\pagebreak
+\begin{lstlisting}[language=bnf]
+constant ::= integer-constant
+ | floating-constant
+ | enumeration-constant
+ | character-constant
+ | vector-constant
+
+integer-constant ::= decimal-constant
+ | octal-constant
+ | hexadecimal-constant
+
+decimal-constant ::= nonzero-digit
+ | decimal-constant digit
+
+octal-constant ::= 0
+ | octal-constant octal-digit
+
+hexadecimal-constant ::= hexdecimal-prefix
+ hexadecimal-digit
+ | hexadecimal-digit
+ hexadecimal-constant
+
+hexadecimal-prefix: ::= 0x | 0X
+
+nonzero-digit ::= 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8
+ | 9
+
+octal-digit ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7
+
+hexadecimal-digit ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7
+ | 8 | 9 | a | b | c | d | e | f
+ | A | B | C | D | E | F
+\end{lstlisting}
-\subsubsection{Comments}
-Except within a character constant, a string literal, or a comment, the characters /* introduce a comment. The contents of such a comment are examined only to find the characters */ that terminate it. (Thus /* .. */ comments do not nest.)
-
-Expect within a character constant, a string literal, or a comment, the character // introduces a comment that includes all characters up to, but not including, the next new-line character. The contents of such a comment are examined only to find the terminating new-line character.
-
-\begin{small}
-EXAMPLE
-\end{small}
-\begin{lstlisting}[language=C]
-"a//b" // four-character string literal
-#include "//e" // undefined behavior
-// */ // comment, not syntax error
-a = b/**//c; // same as a = b / c;
-/*//*/ foo(); // same as foo();
+%% ->-> String literals %%
+\subsubsection{String literals}
+\begin{lstlisting}[language=bnf]
+string-literal := " s-char-sequence "
+
+s-char-sequence := s-char
+ | s-char-sequence s-char
+
+s-char := ` | ! | @ | # | $ | % | ^ | & | *
+ | ( | ) | _ | - | + | = | { | } | [
+ | ] | | | : | ; | ' | < | , | > | .
+ | ? | / | 1 | 2 | 3 | 4 | 5 | 6 | 7
+ | 8 | 9 | 0 | q | w | e | r | t | y
+ | u | i | o | p | a | s | d | f | g
+ | h | j | k | l | z | x | c | v | b
+ | n | m | Q | W | E | R | T | Y | U
+ | I | O | P | A | S | D | F | G | |
+ | H | J | K | L | Z | X | C | V | B
+ | N | M
\end{lstlisting}
+\paragraph*{Description}
+A character string literal is a sequence of zero or more characters enclosed in
+double-quotes, as in "xyz".
+\linebreak
-\subsection{Expressions}
-An expression is a sequence of operators and operands that specifies computation of a value, or that designates an object or function, or that generates side effects, or that performs a combination thereof.
+The same considerations apply to each element of the sequence in a character string
+literal as if it where an integer character constant, except that the single-quote
+' is representable either by itself or by the escape sequence \textbackslash', but
+the double-quote " shall be represented by the escape sequence \textbackslash".
-Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be read only to determine the value to be stored.
+\paragraph*{Semantics}
+In translation stage six, the character sequences specified by any sequence of adjacent
+character string literal tokens are concatenated into a single character sequence.
-The grouping of operators and operands is indicated by the syntax. Except as specified later (for the function-call(), \&\&, \textpipe\textpipe, ?:, and comma operators), the order of evaluation of subexpressions and the order in which side effects take place are both unspecified.
+%% ->-> Punctuators %%
+\subsubsection{Punctuators}
+TODO: BNF
-Some operators (the unary \~\space, and the binary operators \textless\textless, \textgreater\textgreater, \&, \^\space, and \textpipe, collectively describe as bitwise operators) are required to have operands that have integer type.
+A punctuator is a symbol that has independent syntactic and semantic significance.
+Depending on context, it may specify an operation to be performed (which in turn
+may yield a value or a function designator, produce a side effect, or some combination
+thereof) in which case it is known as an operator (other forms of operator also exist
+in some contexts). An operand is an item on which an operator acts.
+\linebreak
-An object shall have its stored value accessed only by an lvalue expression that has one of the following types:
-\begin{enumerate}
- \item A type compatible with the effective type of the object,
- \item A qualified version of a type compatible with the effective type of the object,
-\end{enumerate}
+TODO: Trigraphs \& Digraphs
+\subsubsection{Header names}
+TODO
+\subsubsection{Preprocessing numbers}
+TODO
+\subsubsection{Comments}
+Except within a character constant, a string literal, or a comment, the characters /*
+introduce a comment. The contents of such a comment are examined only to identify
+characters and to find the characters /* that terminate it.
+\linebreak
+
+Except within a character constant, a string literal, or a comment, the characters //
+introduce a comment that includes all characters up to, but not including, the next
+new-line character. The contents of such a comment are examined only to identify
+characters and to find the terminating new-line characters.
+\linebreak
+
+%% -> Expressions %%
+\subsection{Expressions}
+An expression is a sequence of operators and operands that specifies computation of a
+value, or that designates an object or function, or that generates side effects, or that
+performs a combination thereof.
+\linebreak
+
+Between the previous and next sequence point an object shall have its stored value
+modified at most once by the evaluation of an expression. Furthermore, the prior value
+shall be read only to determine the value to be stored.
+\linebreak
+
+The grouping of operators and operands is indicated by the syntax. Except as specified
+later (for the function call (), \&\&, \textbar\textbar ?:, and comma operators), the
+order of evaluation of sub-expressions and the order in which side effects take place
+are both unspecified.
+\linebreak
+
+Some operators (the unary \textasciitilde operator, and the binary operators \textless
+\textless, \textgreater\textgreater, \&, \^, and \textbar, collectively describe bitwise
+operators) are required to have operands that are either integer, or floating point with
+zero points of decimal precision.
+\linebreak
+
+If an exceptional condition occurs during the evaluation of an expression (that is, if
+the result is not mathematically defined or not in the range or representable values for
+its type), the behavior is undefined.
+
+%% ->-> Primary expressions %%
\subsubsection{Primary expressions}
\paragraph*{Syntax}
-\begin{tabular}{ l }
- identifier \\
- constant \\
- string-literal \\
- ( expression )
-\end{tabular}
+\begin{lstlisting}[language=bnf]
+primary-expression := identifier
+ | constant
+ | string-literal
+ ( expression )
+\end{lstlisting}
\paragraph*{Semantics}
-An identifier is a primary expression, provided it has been declares as a designating object (in which case it is an lvalue) or a function (in which case it is a function designator).
-
-A constant is a primary expression, with type as detailed in \ref{sec:constants}.
-
-\subsection{Constant Expressions}
-\subsubsection{Description}
-A constant expression can be evaluated during translation rather than runtime, and accordingly can be used in any place that a constant may be.
-\subsubsection{Constraints}
-Constant expressions shall not contain assignment, increment, decrement, function-call, or comma operators, except when they're contained within a subexpression that is not evaluated.
-
-Each constant expression shall evaluate to a constant that is in the range of representable values for it's designated type.
-\subsubsection{Semantics}
-An expression that evaluates to a constant is required in several contexts. If a floating expression is evaluated in the translation environment, the arithmetic precision and range shall be at least as great as if they expression were being evaluated in the execution environment.
-
-An integer constant expression shall have integral type, and shall only have operands that are integer constants, enumeration constants, character constants, and floating constants that are the immediate operands of casts.
-
-The semantic rules for the evaluation of a constant expression are the same as for nonconstant expressions.
+An identifier is a primary expression, provided it has been declared as designating an
+object(in which case it is an lvalye) or a function(in which case it is a function
+designator).
+\linebreak
-An implementation may accept other forms of constant expressions
-\subsection{Declarations}
-\subsubsection{Constraints}
-All declarations shall declare at least a declarator (other than the parameters of a function), a tag, or members of an enumeration.
+A constant is a primary expression. Its type depends on its form and value.
+\linebreak
-All declarations in the same scope that refer to the same object or function shall specify compatible types.
-\subsubsection{Semantics}
-A declaration specifies the interpretation and attributes of a set of identifiers. A definition of an identifier is a declaration for that identifier that:
-\begin{enumerate}
- \item for an object, causes storage to be reversed for that object;
- \item for a function, includes the function body;
- \item for an enumeration constant or typedef name, is the (only) declaration of the identifier.
-\end{enumerate}
+A string literal is a primary expression. It is an lvalue.
+\linebreak
+A parenthesized expression is a primary expression. Its type and value identical to
+those of the unparenthesized expression. It is an lvalue, a function designator, or a
+void expression if the unparenthesized expression is, respectively, an lvalue, a
+function designator, or a void expression.
-\subsection{Statement and blocks}
-A statement specifies a specific action to be preformed. Execpt as indicated, statements are executed in sequence.
+\bibliographystyle{abbrv}
+\bibliography{main}
\end{document}
projects / xonotic / gmqcc.git / commitdiff