File: dump.html

package info (click to toggle)
tendra-doc 4.1.2-8
links: PTS
area: main
in suites: etch, etch-m68k, jessie, jessie-kfreebsd, lenny, squeeze
size: 2,608 kB
ctags: 1,566
sloc: makefile: 31; sh: 3
file content (967 lines) | stat: -rw-r--r-- 31,204 bytes
parent folder | download | duplicates (4)
<!-- Crown Copyright (c) 1998 -->
<HTML>
<HEAD>
<TITLE>
C++ Producer Guide: Symbol table dump 
</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#400080" ALINK="#FF0000">

<H1>C++ Producer Guide</H1>
<H3>March 1998</H3>
<A HREF="link.html"><IMG SRC="../images/next.gif" ALT="next section"></A>
<A HREF="token.html"><IMG SRC="../images/prev.gif" ALT="previous section"></A>
<A HREF="index.html"><IMG SRC="../images/top.gif" ALT="current document"></A>
<A HREF="../index.html"><IMG SRC="../images/home.gif" ALT="TenDRA home page">
</A>
<IMG SRC="../images/no_index.gif" ALT="document index"><P>
<HR>

<DL>
<DT><A HREF="#lex"><B>2.4.1</B> - Lexical elements</A><DD>
<DT><A HREF="#main"><B>2.4.2</B> - Overall syntax</A><DD>
<DT><A HREF="#loc"><B>2.4.3</B> - File locations</A><DD>
<DT><A HREF="#id"><B>2.4.4</B> - Identifiers</A><DD>
<DT><A HREF="#type"><B>2.4.5</B> - Types</A><DD>
<DT><A HREF="#sort"><B>2.4.6</B> - Sorts</A><DD>
<DT><A HREF="#args"><B>2.4.7</B> - Token applications</A><DD>
<DT><A HREF="#error"><B>2.4.8</B> - Errors</A><DD>
<DT><A HREF="#file"><B>2.4.9</B> - File inclusions</A><DD>
<DT><A HREF="#string"><B>2.4.10</B> - String literals</A><DD>
</DL>
<HR>

<H2>2.4. Symbol table dump</H2>
<P>
The symbol table dump provides a method whereby third party tools
can interface with the C and C++ producers.  The producer outputs
information on the identifiers declared within a source file, their
uses etc. into a file which can then be post-processed by a separate
tool. Any error messages and warnings can also be included in this
file, allowing more sophisticated error presentation tools to be written.
</P>
<P>
The file to be used as the symbol table output file, plus details
of what information is to be included in the dump file can be specified
using the <A HREF="man.html#dump"><CODE>-d</CODE> command-line option</A>.
The format of the dump file is described below; a 
<A HREF="dump1.html">summary of the syntax</A> is given as an annex.
</P>

<HR>
<H3><A NAME="lex">2.4.1. Lexical elements</A></H3>
<P>
A symbol table dump file consists of a sequence of characters giving
information on identifiers, errors etc. arising from a translation
unit. The fundamental lexical tokens are a <I>number</I>, consisting
of a sequence of decimal digits, and a <I>string</I>, consisting of
a sequence of characters enclosed in angle braces.  A <I>string</I>
can have one of two forms: 
<PRE>
	<I>string</I> :
		&lt;<I>characters</I>&gt;
		&amp;<I>number</I>&lt;<I>characters</I>&gt;
</PRE>
In the first form, the <I>characters</I> are terminated by the first
<CODE>&gt;</CODE> character encountered.  In the second form, the
number of characters is given by the preceding <I>number</I>.  No
white space is allowed either before or after the <I>number</I>. 
To aid parsers, the C++ producer always uses the second form for strings
containing more than 100 characters.  There are no escape characters
in strings; the 
<I>characters</I> can contain any characters, including newlines and
<CODE>#</CODE>, except that the first form cannot contain a 
<CODE>&gt;</CODE> character. 
</P>
<P>
Space, tab and newline characters are white space.  Comments begin
with 
<CODE>#</CODE> and run to the end of the line.  Comments are treated
as white space.  All other characters are treated as distinct lexical
tokens. 
</P>

<HR>
<H3><A NAME="main">2.4.2. Overall syntax</A></H3>
<P>
A symbol table dump file takes the form of a list of commands of various
kinds conveying information on the analysed file.  This can be represented
as follows: 
<PRE>
	<I>dump-file</I> :
		<I>command-list<SUB>opt</SUB></I>

	<I>command-list</I> :
		<I>command command-list<SUB>opt</SUB></I>

	<I>command</I> :
		<I>version-command</I>
		<I>identifier-command</I>
		<I>scope-command</I>
		<I>override-command</I>
		<I>base-command</I>
		<I>api-command</I>
		<I>template-command</I>
		<I>promotion-command</I>
		<I>error-command</I>
		<I>path-command</I>
		<I>file-command</I>
		<I>include-command</I>
		<I>string-command</I>
</PRE>
The various kinds of command are discussed below.  The first command
in the dump file should be of the form: 
<PRE>
	<I>version-command</I> :
		V <I>number number string</I>
</PRE>
where the two numbers give the version of the dump file format (the
version described here is 1.1 so both numbers should be 1) and the
string gives the language being represented, for example, 
<CODE>&lt;C++&gt;</CODE>. 
</P>

<HR>
<H3><A NAME="loc">2.4.3. File locations</A></H3>
<P>
A location within a source file can be specified using three 
<I>number</I>s and two <I>string</I>s.  These give respectively, the
column number, the line number taking <CODE>#line</CODE> directives
into account, the line number not taking <CODE>#line</CODE> directives
into account, the file name taking <CODE>#line</CODE> directives into
account, and the file name not taking <CODE>#line</CODE> directives
into account.  Any or all of the trailing elements can be replaced
by 
<CODE>*</CODE> to indicate that they have not changed relative to
the last <I>location</I> given.  Note that for the two line numbers,
unchanged means that the difference of the line numbers, taking 
<CODE>#line</CODE> directives into account or not, is unchanged. 
Thus: 
<PRE>
	<I>location</I> :
		<I>number number number string string</I>
		<I>number number number string</I> *
		<I>number number number</I> *
		<I>number number</I> *
		<I>number</I> *
		*
</PRE>
Note that there is a concept of the <A NAME="crt_loc">current file
location</A>, relative to which other locations are given.  The initial
value of the current file location is undefined.  Unless otherwise
stated, all <I>location</I> elements update the current file location.
</P>

<HR>
<H3><A NAME="id">2.4.4. Identifiers</A></H3>
<P>
Each identifier is represented in the symbol table dump by a unique
number.  The same number always represents the same identifier. 
</P>

<H4><A NAME="hashid">Identifier names</A></H4>
<P>
The number representing an identifier is introduced in the first declaration
or use of that identifier and thereafter the number alone is used
to denote the identifier: 
<PRE>
	<I>identifier</I> :
		<I>number</I> = <I>identifier-name access<SUB>opt</SUB> scope-identifier</I>
		<I>number</I>
</PRE>
</P>
<P>
The identifier name is given by: 
<PRE>
	<I>identifier-name</I> :
		<I>string</I>
		C <I>type</I>
		D <I>type</I>
		O <I>string</I>
		T <I>type</I>
</PRE>
denoting respectively, a simple identifier name, a constructor for
a type, a destructor for a type, an overloaded operator function name,
and a conversion function name.  The empty string is used for anonymous
identifiers. 
</P>
<P>
The optional identifier access is given by: 
<PRE>
	<I>access</I> :
		N
		B
		P
</PRE>
denoting <CODE>public</CODE>, <CODE>protected</CODE> and 
<CODE>private</CODE> respectively.  An absent <I>access</I> is equivalent
to <CODE>public</CODE>.  Note that all identifiers, not just class
members, can have access specifiers; however the access of a non-member
is always <CODE>public</CODE>. 
</P>
<P>
The <A HREF="#scope">scope</A> (i.e. class, namespace, block etc.)
in which an identifier is declared is given by: 
<PRE>
	<I>scope-identifier</I> :
		<I>identifier</I>
		*
</PRE>
denoting either a named or an unnamed scope. 
</P>

<H4><A NAME="use">Identifier uses</A></H4>
<P>
Each declaration or use of an identifier is represented by a command
of the form: 
<PRE>
	<I>identifier-command</I> :
		D <I>identifier-info type-info</I>
		M <I>identifier-info type-info</I>
		T <I>identifier-info type-info</I>
		Q <I>identifier-info</I>
		U <I>identifier-info</I>
		L <I>identifier-info</I>
		C <I>identifier-info</I>
		W <I>identifier-info type-info</I>
</PRE>
where: 
<PRE>
	<I>identifier-info</I> :
		<I>identifier-key location identifier</I>
</PRE>
gives the kind of identifier being declared or used, the location
of the declaration or use, and the number associated with the identifier.
Each declaration may, depending on the <I>identifier-key</I>, associate
various <I>type-info</I> with the identifier, giving its type etc.
</P>
<P>
The various kinds of <I>identifier-command</I> are described below.
Any can be preceded by <CODE>I</CODE> to indicate an implicit declaration
or use.  <CODE>D</CODE> denotes a definition.  <CODE>M</CODE> (make)
denotes a declaration.  <CODE>T</CODE> denotes a tentative definition
(C only).  <CODE>Q</CODE> denotes the end of a definition, for those
identifiers such as classes and functions whose definitions may be
spread over several lines.  <CODE>U</CODE> denotes an undefine operation
(such as <CODE>#undef</CODE> for macro identifiers).  <CODE>C</CODE>
denotes a call to a function identifier; <CODE>L</CODE> (load) denotes
other identifier uses.  Finally <CODE>W</CODE> denotes implicit type
information such as the C producer gleans from its 
<A HREF="pragma.html#weak">weak prototype analysis</A>. 
</P>
<P>
The various <I>identifier-key</I>s are their associated <I>type-info</I>
fields are given by the following table: 
</P>
<CENTER>
<TABLE BORDER>
<TR><TH>Key</TH>
<TH>Type information</TH>
<TH>Description</TH>
<TR><TD ALIGN=CENTER><CODE>K</CODE></TD>
<TD><CODE>*</CODE></TD>
<TD>keyword</TD>
<TR><TD ALIGN=CENTER><CODE>MO</CODE></TD>
<TD><I>sort</I></TD>
<TD>object macro</TD>
<TR><TD ALIGN=CENTER><CODE>MF</CODE></TD>
<TD><I>sort</I></TD>
<TD>function macro</TD>
<TR><TD ALIGN=CENTER><CODE>MB</CODE></TD>
<TD><I>sort</I></TD>
<TD>built-in macro</TD>
<TR><TD ALIGN=CENTER><CODE>TC</CODE></TD>
<TD><I>type</I></TD>
<TD>class tag</TD>
<TR><TD ALIGN=CENTER><CODE>TS</CODE></TD>
<TD><I>type</I></TD>
<TD>structure tag</TD>
<TR><TD ALIGN=CENTER><CODE>TU</CODE></TD>
<TD><I>type</I></TD>
<TD>union tag</TD>
<TR><TD ALIGN=CENTER><CODE>TE</CODE></TD>
<TD><I>type</I></TD>
<TD>enumeration tag</TD>
<TR><TD ALIGN=CENTER><CODE>TA</CODE></TD>
<TD><I>type</I></TD>
<TD><CODE>typedef</CODE> name</TD>
<TR><TD ALIGN=CENTER><CODE>NN</CODE></TD>
<TD><CODE>*</CODE></TD>
<TD>namespace name</TD>
<TR><TD ALIGN=CENTER><CODE>NA</CODE></TD>
<TD><I>scope-identifier</I></TD>
<TD>namespace alias</TD>
<TR><TD ALIGN=CENTER><CODE>VA</CODE></TD>
<TD><I>type</I></TD>
<TD>automatic variable</TD>
<TR><TD ALIGN=CENTER><CODE>VP</CODE></TD>
<TD><I>type</I></TD>
<TD>function parameter</TD>
<TR><TD ALIGN=CENTER><CODE>VE</CODE></TD>
<TD><I>type</I></TD>
<TD><CODE>extern</CODE> variable</TD>
<TR><TD ALIGN=CENTER><CODE>VS</CODE></TD>
<TD><I>type</I></TD>
<TD><CODE>static</CODE> variable</TD>
<TR><TD ALIGN=CENTER><CODE>FE</CODE></TD>
<TD><I>type identifier<SUB>opt</SUB></I></TD>
<TD><CODE>extern</CODE> function</TD>
<TR><TD ALIGN=CENTER><CODE>FS</CODE></TD>
<TD><I>type identifier<SUB>opt</SUB></I></TD>
<TD><CODE>static</CODE> function</TD>
<TR><TD ALIGN=CENTER><CODE>FB</CODE></TD>
<TD><I>type identifier<SUB>opt</SUB></I></TD>
<TD>built-in operator function</TD>
<TR><TD ALIGN=CENTER><CODE>CF</CODE></TD>
<TD><I>type identifier<SUB>opt</SUB></I></TD>
<TD>member function</TD>
<TR><TD ALIGN=CENTER><CODE>CS</CODE></TD>
<TD><I>type identifier<SUB>opt</SUB></I></TD>
<TD><CODE>static</CODE> member function</TD>
<TR><TD ALIGN=CENTER><CODE>CV</CODE></TD>
<TD><I>type identifier<SUB>opt</SUB></I></TD>
<TD>virtual member function</TD>
<TR><TD ALIGN=CENTER><CODE>CM</CODE></TD>
<TD><I>type</I></TD>
<TD>data member</TD>
<TR><TD ALIGN=CENTER><CODE>CD</CODE></TD>
<TD><I>type</I></TD>
<TD><CODE>static</CODE> data member</TD>
<TR><TD ALIGN=CENTER><CODE>E</CODE></TD>
<TD><I>type</I></TD>
<TD>enumerator</TD>
<TR><TD ALIGN=CENTER><CODE>L</CODE></TD>
<TD><CODE>*</CODE></TD>
<TD>label</TD>
<TR><TD ALIGN=CENTER><CODE>XO</CODE></TD>
<TD><I>sort</I></TD>
<TD>object token</TD>
<TR><TD ALIGN=CENTER><CODE>XF</CODE></TD>
<TD><I>sort</I></TD>
<TD>procedure token</TD>
<TR><TD ALIGN=CENTER><CODE>XP</CODE></TD>
<TD><I>sort</I></TD>
<TD>token parameter</TD>
<TR><TD ALIGN=CENTER><CODE>XT</CODE></TD>
<TD><I>sort</I></TD>
<TD>template parameter</TD>
</TABLE>
</CENTER>
<P>
The function identifier keys can optionally be followed by 
<CODE>C</CODE> indicating that the function has C linkage, and 
<CODE>I</CODE> indicating that the function is inline.  By default,
functions declared in a C++ dump file have C++ linkage and functions
declared in a C dump file have C linkage.  The optional 
<I>identifier</I> which forms part of the <I>type-info</I> of these
functions is used to form linked lists of overloaded functions. 
</P>

<H4><A NAME="scope">Identifier scopes</A></H4>
<P>
Each identifier belongs to a scope, called its parent scope, in which
it is declared.  For example, the parent of a member of a class is
the class itself.  This information is expressed in an identifier
declaration using a <I>scope-identifier</I>.  In addition to the obvious
scopes such as classes and namespaces, there are other scopes such
as blocks in function definitions.  It is possible to introduce dummy
identifiers to name such scopes.  The parent of such a dummy identifier
will be the enclosing scope identifier, so these dummy identifiers
naturally represent the block structure.  The parent of the top-level
block in a function definition can be considered to be the function
itself. 
</P>
<P>
Information on the start and end of such scopes is given by: 
<PRE>
	<I>scope-command</I> :
		SS <I>scope-key location identifier</I>
		SE <I>scope-key location identifier</I>
</PRE>
where: 
<PRE>
	<I>scope-key</I> :
		N
		S
		B
		D
		H
		CT
		CF
		CC
</PRE>
gives the kind of scope involved: a namespace, a class, a block, some
other declarative scope, a declaration block (see below), a true conditional
scope, a false conditional scope or a target dependent conditional
scope. 
</P>
<P>
A declaration block is a sequence of declarations enclosed in directives
of the form: 
<PRE>
	#pragma TenDRA declaration block <I>identifier</I> begin
	....
	#pragma TenDRA declaration block end
</PRE>
This allows the sequence of declarations to be associated with the
given 
<I>identifier</I> in the symbol dump file.  This technique is used
in the API description files to aid analysis tools in determining
which declarations are part of the API. 
</P>

<H4><A NAME="scope">Other identifier information</A></H4>
<P>
Other information associated with an identifier may be expressed using
other dump commands.  For example: 
<PRE>
	<I>override-command</I> :
		O <I>identifier identifier</I>
</PRE>
is used to express the fact that the two <I>identifier</I>s are virtual
member functions, the first of which overrides the second. 
</P>
<P>
The command: 
<PRE>
	<I>base-command</I> :
		B <I>identifier-key identifier base-graph</I>

	<I>base-graph</I> :
		<I>base-class</I>
		<I>base-class</I> ( <I>base-list</I> )

	<I>base-class</I> :
		<I>number</I> = V<I><SUB>opt</SUB> access<SUB>opt</SUB> type-name</I>
		<I>number</I> :

	<I>base-list</I> :
		<I>base-graph base-list<SUB>opt</SUB></I>

</PRE>
associates a base class graph with a class identifier.  Any class
which does not have an associated <I>base-command</I> can be assumed
to have no base classes.  Each node in the graph is a <I>type-name</I>
with an associated list of base classes.  A <CODE>V</CODE> is used
to indicate a virtual base class.  Each node is numbered; duplicate
numbers are used to indicate bases identified via the virtual base
class structure.  Any base class can then be referred to as: 
<PRE>
	<I>base-number</I> :
		<I>number</I> : <I>type-name</I>
</PRE>
indicating the base class with the given number in the given class.
</P>
<P>
The command: 
<PRE>
	<I>api-command</I> :
		X <I>identifier-key identifier string</I>
</PRE>
associates the external token name given by the <I>string</I> with
the given tokenised identifier. 
</P>
<P>
The command: 
<PRE>
	<I>template-command</I> :
		Z <I>identifier-key identifier token-application specialise-info</I>
</PRE>
is used to introduce an identifier corresponding to an instance of
a template, <I>token-application</I>.  This instance may correspond
to a specialisation of the primary template; this information is represented
by: 
<PRE>
	<I>specialise-info</I> :
		<I>identifier</I>
		<I>token-application</I>
		*
</PRE>
where <CODE>*</CODE> indicates a non-specialised instance. 
</P>

<HR>
<H3><A NAME="type">2.4.5. Types</A></H3>
<P>
The <A NAME="built-in">built-in types</A> are represented in the symbol
table dump as follows: 
</P>
<CENTER>
<TABLE BORDER>
<TR><TH>Type</TH>
<TH>Encoding</TH>
<TH>Type</TH>
<TH>Encoding</TH>
<TR><TD ALIGN=CENTER>char</TD>
<TD ALIGN=CENTER><CODE>c</CODE></TD>
<TD ALIGN=CENTER>float</TD>
<TD ALIGN=CENTER><CODE>f</CODE></TD>
<TR><TD ALIGN=CENTER>signed char</TD>
<TD ALIGN=CENTER><CODE>Sc</CODE></TD>
<TD ALIGN=CENTER>double</TD>
<TD ALIGN=CENTER><CODE>d</CODE></TD>
<TR><TD ALIGN=CENTER>unsigned char</TD>
<TD ALIGN=CENTER><CODE>Uc</CODE></TD>
<TD ALIGN=CENTER>long double</TD>
<TD ALIGN=CENTER><CODE>r</CODE></TD>
<TR><TD ALIGN=CENTER>signed short</TD>
<TD ALIGN=CENTER><CODE>s</CODE></TD>
<TD ALIGN=CENTER>void</TD>
<TD ALIGN=CENTER><CODE>v</CODE></TD>
<TR><TD ALIGN=CENTER>unsigned short</TD>
<TD ALIGN=CENTER><CODE>Us</CODE></TD>
<TD ALIGN=CENTER>(bottom)</TD>
<TD ALIGN=CENTER><CODE>u</CODE></TD>
<TR><TD ALIGN=CENTER>signed int</TD>
<TD ALIGN=CENTER><CODE>i</CODE></TD>
<TD ALIGN=CENTER>bool</TD>
<TD ALIGN=CENTER><CODE>b</CODE></TD>
<TR><TD ALIGN=CENTER>unsigned int</TD>
<TD ALIGN=CENTER><CODE>Ui</CODE></TD>
<TD ALIGN=CENTER>ptrdiff_t</TD>
<TD ALIGN=CENTER><CODE>y</CODE></TD>
<TR><TD ALIGN=CENTER>signed long</TD>
<TD ALIGN=CENTER><CODE>l</CODE></TD>
<TD ALIGN=CENTER>size_t</TD>
<TD ALIGN=CENTER><CODE>z</CODE></TD>
<TR><TD ALIGN=CENTER>unsigned long</TD>
<TD ALIGN=CENTER><CODE>Ul</CODE></TD>
<TD ALIGN=CENTER>wchar_t</TD>
<TD ALIGN=CENTER><CODE>w</CODE></TD>
<TR><TD ALIGN=CENTER>signed long long</TD>
<TD ALIGN=CENTER><CODE>x</CODE></TD>
<TD ALIGN=CENTER>-</TD>
<TD ALIGN=CENTER>-</TD>
<TR><TD ALIGN=CENTER>unsigned long long</TD>
<TD ALIGN=CENTER><CODE>Ux</CODE></TD>
<TD ALIGN=CENTER>-</TD>
<TD ALIGN=CENTER>-</TD>
</TABLE>
</CENTER>
<P>
Named types (classes, enumeration types etc.) can be represented by
the corresponding identifier or token application: 
<PRE>
	<I>type-name</I> :
		<I>identifier</I>
		<I>token-application</I>
</PRE>
<A NAME="composite">Composite and qualified types</A> are represented
in terms of their subtypes as follows: 
</P>
<CENTER>
<TABLE BORDER>
<TR><TH>Type</TH>
<TH>Encoding</TH>
<TR><TD><CODE>const</CODE> type</TD>
<TD><CODE>C</CODE> <I>type</I></TD>
<TR><TD><CODE>volatile</CODE> type</TD>
<TD><CODE>V</CODE> <I>type</I></TD>
<TR><TD>pointer type</TD>
<TD><CODE>P</CODE> <I>type</I></TD>
<TR><TD>reference type</TD>
<TD><CODE>R</CODE> <I>type</I></TD>
<TR><TD>pointer to member type</TD>
<TD><CODE>M</CODE> <I>type-name</I> <CODE>:</CODE> <I>type</I></TD>
<TR><TD>function type</TD>
<TD><CODE>F</CODE> <I>type parameter-types</I></TD>
<TR><TD>array type</TD>
<TD><CODE>A</CODE> <I>nat<SUB>opt</SUB></I> <CODE>:</CODE> <I>type</I></TD>
<TR><TD>bitfield type</TD>
<TD><CODE>B</CODE> <I>nat</I> <CODE>:</CODE> <I>type</I></TD>
<TR><TD>template type</TD>
<TD><CODE>t</CODE> <I>parameter-list<SUB>opt</SUB></I> <CODE>:</CODE> <I>type</I></TD>
<TR><TD>promotion type</TD>
<TD><CODE>p</CODE> <I>type</I></TD>
<TR><TD>arithmetic type</TD>
<TD><CODE>a</CODE> <I>type</I> <CODE>:</CODE> <I>type</I></TD>
<TR><TD>integer literal type</TD>
<TD><CODE>n</CODE> <I>lit-base<SUB>opt</SUB> lit-suffix<SUB>opt</SUB></I></TD>
<TR><TD>weak function prototype (C only)</TD>
<TD><CODE>W</CODE> <I>type parameter-types</I></TD>
<TR><TD>weak parameter type (C only)</TD>
<TD><CODE>q</CODE> <I>type</I></TD>
</TABLE>
</CENTER>
<P>
Other types can be represented by their textual representation using
the form <CODE>Q</CODE> <I>string</I>, or by <CODE>*</CODE>, indicating
an unknown type. 
</P>
<P>
The parameter types for a function type are represented as follows:
<PRE>
	<I>parameter-types</I> :
		: <I>exception-spec<SUB>opt</SUB> func-qualifier<SUB>opt</SUB></I> :
		. <I>exception-spec<SUB>opt</SUB> func-qualifier<SUB>opt</SUB></I> :
		. <I>exception-spec<SUB>opt</SUB> func-qualifier<SUB>opt</SUB></I> .
		, <I>type parameter-types</I>
</PRE>
where the <CODE>::</CODE> form indicates that there are no further
parameters, the <CODE>.:</CODE> form indicates that the parameters
are terminated by an ellipsis, and the <CODE>..</CODE> form indicates
that no information is available on the further parameters (this can
only happen with non-prototyped functions in C).  The function qualifiers
are given by: 
<PRE>
	<I>func-qualifier</I> :
		C <I>func-qualifier<SUB>opt</SUB></I>
		V <I>func-qualifier<SUB>opt</SUB></I>
</PRE>
representing <CODE>const</CODE> and <CODE>volatile</CODE> member functions.
The function exception specifier is given by: 
<PRE>
	<I>exception-spec</I> :
		( <I>exception-list<SUB>opt</SUB></I> )

	<I>exception-list</I> :
		<I>type</I>
		<I>type</I> , <I>exception-list</I>
</PRE>
with an absent exception specifier, as in C++, indicating that any
exception may be thrown. 
</P>
<P>
Array and bitfield sizes are represented as follows: 
<PRE>
	<I>nat</I> :
		+ <I>number</I>
		- <I>number</I>
		<I>identifier</I>
		<I>token-application</I>
		<I>string</I>
</PRE>
where a <I>string</I> is used to hold a textual representation of
complex values. 
</P>
<P>
Template types are represented by a list of template parameters, which
will have previously been declared using the <CODE>XT</CODE> identifier
key, followed by the underlying type expressed in terms of these parameters.
The parameters are represented as follows: 
<PRE>
	<I>parameter-list</I> :
		<I>identifier</I>
		<I>identifier</I> , <I>parameter-list</I>
</PRE>
</P>
<P>
Integer literal types are represented by the value of the literal
followed by a representation of the literal base and suffix.  These
are given by: 
<PRE>
	<I>lit-base</I> :
		O
		X
</PRE>
representing octal and hexadecimal literals respectively (decimal
is the default), and: 
<PRE>
	<I>lit-suffix</I> :
		U
		l
		Ul
		x
		Ux
</PRE>
representing the <CODE>U</CODE>, <CODE>L</CODE>, <CODE>UL</CODE>,
<CODE>LL</CODE> and <CODE>ULL</CODE> suffixes respectively. 
</P>
<P>
Target dependent integral promotion types are represented using 
<CODE>p</CODE>, so for example the promotion of <CODE>unsigned short</CODE>
is represented as <CODE>pUs</CODE>.  Information on the other cases,
where the promotion type is known, can be given in a command of the
form: 
<PRE>
	<I>promotion-command</I> :
		P <I>type</I> : <I>type</I>
</PRE>
Thus the fact that the promotion of <CODE>short</CODE> is <CODE>int</CODE>
would be expressed by the command <CODE>Ps:i</CODE>. 
</P>

<HR>
<H3><A NAME="sort">2.4.6. Sorts</A></H3>
<P>
A <I>sort</I> in the symbol table dump corresponds to the sort of
a token declared in the <A HREF="token.html#spec"><CODE>#pragma token</CODE>
syntax</A>.  Expression tokens are represented as follows: 
<PRE>
	<I>expression-sort</I> :
		ZEL <I>type</I>
		ZER <I>type</I>
		ZEC <I>type</I>
		ZN
</PRE>
corresponding to <CODE>lvalue</CODE>, <CODE>rvalue</CODE> and 
<CODE>const</CODE> <CODE>EXP</CODE> tokens of the given type, and
<CODE>NAT</CODE> or <CODE>INTEGER</CODE> tokens, respectively. Statement
tokens are represent by: 
<PRE>
	<I>statement-sort</I> :
		ZS
</PRE>
</P>
<P>
Type tokens are represented as follows: 
<PRE>
	<I>type-sort</I> :
		ZTO
		ZTI
		ZTF
		ZTA
		ZTP
		ZTS
		ZTU
</PRE>
corresponding to <CODE>TYPE</CODE>, <CODE>VARIETY</CODE>, <CODE>FLOAT</CODE>,
<CODE>ARITHMETIC</CODE>, <CODE>SCALAR</CODE>, <CODE>STRUCT</CODE>
or 
<CODE>CLASS</CODE>, and <CODE>UNION</CODE> token respectively.  There
are corresponding <CODE>TAG</CODE> forms: 
<PRE>
	<I>tag-type-sort</I> :
		ZTTS
		ZTTU
</PRE>
</P>
<P>
Member tokens are represented using: 
<PRE>
	<I>member-sort</I> :
		ZM <I>type</I> : <I>type-name</I>
</PRE>
where the first type gives the member type and the second gives the
parent structure or union type. 
</P>
<P>
Procedure tokens can be represented using: 
<PRE>
	<I>proc-sort</I> :
		ZPG <I>parameter-list<SUB>opt</SUB></I> ; <I>parameter-list<SUB>opt</SUB></I> : <I>sort</I>
		ZPS <I>parameter-list<SUB>opt</SUB></I> : <I>sort</I>
</PRE>
The first form corresponds to the more general form of <CODE>PROC</CODE>
token, that expressed using <CODE>{ .... | .... }</CODE>, which has
separate lists of bound and program parameters.  These token parameters
will have previously been declared using the <CODE>XP</CODE> identifier
key.  The second form corresponds to the case where the bound and
program parameter lists are equal, that expressed as a <CODE>PROC</CODE>
token using <CODE>( .... )</CODE>.  A more specialised version of
this second form is a <CODE>FUNC</CODE> token, which is represented
as: 
<PRE>
	<I>func-sort</I> :
		ZF <I>type</I>
</PRE>
</P>
<P>
As noted above, template parameters are represented by a <I>sort</I>.
Template type parameters are represented by <CODE>ZTO</CODE>, while
template expression parameters are represent by <CODE>ZEC</CODE>
(recall that such parameters are always constant expressions).  The
remaining case, template template parameters, can be represented as:
<PRE>
	<I>template-sort</I> :
		ZTt <I>parameter-list<SUB>opt</SUB></I> :
</PRE>
</P>
<P>
Finally, the number of parameters in a macro definition is represented
by a <I>sort</I> of the form: 
<PRE>
	<I>macro-sort</I> :
		ZUO
		ZUF <I>number</I>
</PRE>
corresponding to a object-like macro and a function-like macro with
the given number of parameters, respectively. 
</P>

<HR>
<H3><A NAME="args">2.4.7. Token applications</A></H3>
<P>
Given an identifier representing a <CODE>PROC</CODE> token or a template,
an application of that token or an instance of that template can be
represented using: 
<PRE>
	<I>token-application</I> :
		T <I>identifier</I> , <I>token-argument-list</I> :
</PRE>
where the token or template arguments are given by: 
<PRE>
	<I>token-argument-list</I> :
		<I>token-argument</I>
		<I>token-argument</I> , <I>token-argument-list</I>
</PRE>
Note that the case where there are no arguments is generally just
represented by <I>identifier</I>; this case is specified separately
in the rest of the grammar. 
</P>
<P>
A <I>token-argument</I> can represent a value of any of the sorts
listed above: expressions, integer constants, statements, types, members,
functions and templates.  These are given respectively by: 
<PRE>
	<I>token-argument</I> :
		E <I>expression</I>
		N <I>nat</I>
		S <I>statement</I>
		T <I>type</I>
		M <I>member</I>
		F <I>identifier</I>
		C <I>identifier</I>
</PRE>
where: 
<PRE>
	<I>expression</I> :
		<I>nat</I>

	<I>statement</I> :
		<I>expression</I>

	<I>member</I> :
		<I>identifier</I>
		<I>string</I>
</PRE>
</P>

<HR>
<H3><A NAME="error">2.4.8. Errors</A></H3>
<P>
Each error in the C++ <A HREF="error.html">error catalogue</A> is
represented by a number.  These numbers happen to correspond to the
position of the error within the catalogue, but in general this need
not be the case.  The first use of each error introduces the error
number by associating it with a <I>string</I> giving the error name.
This has the form <CODE>cpp.</CODE><I>error</I> where <I>error</I>
gives an error name from the C++ (<CODE>cpp</CODE>) error catalogue.
Thus: 
<PRE>
	<I>error-name</I> :
		<I>number</I> = <I>string</I>
		<I>number</I>
</PRE>
</P>
<P>
Each error message written to the symbol table dump has the form:
<PRE>
	<I>error-command</I> :
		ES <I>location error-info</I>
		EW <I>location error-info</I>
		EI <I>location error-info</I>
		EF <I>location error-info</I>
		EC <I>error-info</I>
		EA <I>error-argument</I>
</PRE>
denoting constraint errors, warnings, internal errors, fatal errors,
continuation errors and error arguments respectively.  Note that an
error message may consist of several components; the initial error
plus a number of continuation errors.  Each error message may also
have a number of error argument associated with it.  This error information
is given by: 
<PRE>
	<I>error-info</I> :
		<I>error-name number number</I>
</PRE>
where the first <I>number</I> gives the number of error arguments
which should be read, and the second is nonzero to indicate that a
continuation error should be read. 
</P>
<P>
Each error argument has one of the forms: 
<PRE>
	<I>error-argument</I> :
		B <I>base-number</I>
		C <I>scope-identifier</I>
		E <I>expression</I>
		H <I>identifier-name</I>
		I <I>identifier</I>
		L <I>location</I>
		N <I>nat</I>
		S <I>string</I>
		T <I>type</I>
		V <I>number</I>
		V - <I>number</I>
</PRE>
corresponding to the various syntactic categories described above.
Note that a <I>location</I> error argument, while expressed relative
to the 
<A HREF="#crt_loc">current file location</A>, does not change this
location. 
</P>

<HR>
<H3><A NAME="file">2.4.9. File inclusions</A></H3>
<P>
It is possible to include information on header files within the symbol
table dump.  Firstly a number is associated with each directory on
the <CODE>#include</CODE> search path: 
<PRE>
	<I>path-command</I> :
		FD <I>number</I> = <I>string string<SUB>opt</SUB></I>
</PRE>
The first <I>string</I> gives the directory pathname; the second,
if present, gives the associated directory name as specified in the
<A HREF="man.html#directory"><CODE>-N</CODE> command-line option</A>.
</P>
<P>
Now the start and end of each file are marked using: 
<PRE>
	<I>file-command</I> :
		FS <I>location directory</I>
		FE <I>location</I>
</PRE>
where <I>directory</I> gives the number of the directory in the search
path where the file was found, or <CODE>*</CODE> if the file was found
by other means.  It is worth noting that if, for example, a function
definition is the last item in a file, the <CODE>FE</CODE> command
will appear in the symbol table dump before the <CODE>QFE</CODE> command
for the end of the function definition.  This is because lexical analysis,
where the end of file is detected, takes place before parsing, where
the end of function is detected. 
</P>
<P>
A <CODE>#include</CODE> directive, whether explicit or implicit, can
be represented using: 
<PRE>
	<I>include-command</I> :
		FIA <I>location string</I>
		FIQ <I>location string</I>
		FIN <I>location string</I>
		FIS <I>location string</I>
		FIE <I>location string</I>
		FIR <I>location</I>
</PRE>
the first three corresponding to header names of the forms 
<CODE>&lt;....&gt;</CODE>, <CODE>&quot;....&quot;</CODE> and <CODE>[....]</CODE>
respectively, the next two corresponding to <A HREF="man.html#start-up">start-up
</A>
and <A HREF="man.html#end-up">end-up</A> files, and the final form
being used to resume the original file after the <CODE>#include</CODE>
directive has been processed. 
</P>

<HR>
<H3><A NAME="string">2.4.10. String literals</A></H3>
<P>
It is possible to dump information on string literals to the symbol
table dump file using the commands: 
<PRE>
	<I>string-command</I> :
		A <I>location string</I>
		AC <I>location string</I>
		AL <I>location string</I>
		ACL <I>location string</I>
</PRE>
representing string literals, character literals, wide string literals
and wide character literals respectively.  The given <I>string</I>
gives the string text. 
</P>

<HR>
<P><I>Part of the <A HREF="../index.html">TenDRA Web</A>.<BR>Crown
Copyright &copy; 1998.</I></P>
</BODY>
</HTML>