Subversion Repositories tendra.SVN

Rev

Blame | Last modification | View Log | RSS feed

<!-- Crown Copyright (c) 1998 -->
<HTML>
<HEAD>
<TITLE>C Checker Reference Manual: Integral Type Specification</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#400080" ALINK="#FF0000">
<A NAME=S127>
<H1>C Checker Reference Manual</H1>
<H3>January 1998</H3>
<A HREF="tdfc18.html"><IMG SRC="../images/next.gif" ALT="next section"></A>
<A HREF="tdfc16.html"><IMG SRC="../images/prev.gif" ALT="previous section"></A>
<A HREF="tdfc1.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="#S128"><B>C.1 </B> - Specifying integer literal types</A><DD>
<DT><A HREF="#S129"><B>C.2 </B> - The Portability Table</A><DD>
</DL>

<HR>
<H1>C  Integral Type Specification</H1>
<A NAME=S128>
<HR><H2>C.1  <A NAME=2>Specifying integer literal types</H2>
The integer literal pragmas are used to define the method of computing
the type of an integer literal. Integer literals cannot be used in
a program unless the class to which they belong has been described
using an integer literal pragma. Each built-in checking mode includes
some integer literal pragmas describing the semantics appropriate
for that mode. If these built-in modes are inappropriate, then the
user must describe the semantics using the pragma below: <P>
<PRE>
        #pragma integer literal <EM>literal_class lit_class_type_list</EM>
</PRE>
The <EM>literal_class</EM> identifies the type of literal integer
involved. The possibilities are: <P>
<UL>
<LI><CODE>decimal</CODE>
<LI><CODE>octal</CODE>
<LI><CODE>hexadecimal</CODE>
</UL>
Each of these types can optionally be followed by <CODE>unsigned</CODE>
and/or <CODE>long</CODE> to specify an unsigned and/or long type respectively.
<P>
The values of the integer literals of any particular class are divided
into contiguous sub-ranges specified by the <CODE>lit_class_type_list</CODE>
which takes the form below: <P>
<PRE>
    <EM>lit_class_type_list</EM>
        *<EM>int_type_spec</EM>
            <EM>integer_constant int_type_spec</EM> | <EM>lit_class_type_list</EM>
        <EM>int_type_spec</EM> :
            : <EM>type_name</EM>
            * warning<SUB><I>opt</I></SUB> : <EM>identifier</EM>
            ** :
</PRE>
The first integer constant, i1 say, identifies the range [0,i1], the
second, i2 say, identifies the range [i1+1,i2]. The symbol * specifies
the unlimited range upwards from the last integer constant. Each integer
constant must be strictly greater than its predecessor. <P>
Associated with each sub-range is an <EM>int_type_spec</EM> which
is either a type, a procedure token identifier with an optional warning
(see G.9)or a failure. For each sub-range: <P>
<UL>
<LI>If the <EM>int_type_spec</EM> is a type name, then it must be
an integral type and specifies the type associated with literals in
that sub-range. <P>
<LI>If the <CODE>int_type_spec</CODE> is an identifier, then the type
of integer is computed by a procedure token of that name which takes
the integer value as a parameter and delivers its type. The procedure
token must have been declared previously as 
<PRE>
        #pragma token PROC ( VARIETY ) VARIETY
</PRE>
Since the type of the integer is computed by a procedure token which
may be implemented differently on different targets, there is the
option of producing a warning whenever the token is applied.<P>
<LI>If the <EM>int_type_spec</EM> is **, then any integer literal
lying in the associated sub-range will cause the checker to raise
an error.<P>
</UL>
For example:<P>
<PRE>
        #pragma integer literal decimal 0x7fff : int | 0x7fffffff : long | * : unsigned long
</PRE>
divides unsuffixed decimal literals into three ranges: literals in
the range [0, 0x7fff] are of type int, integer literals in the range
[0x7fff, 0x7fffffff] are of type long and the remainder are of type
unsigned long.<P>
There are four pre-defined procedure tokens supplied with the compiler
which are used in the startup files to provide the default specification
for integer literals: <P>
<UL>
<LI><CODE>~lit_int</CODE> is the external identification of a token
that returns the integer type according to the rules of ISO C for
an unsuffixed decimal;<P>
<LI><CODE>~lit_hex </CODE>is the external identification of a token
that returns the integer type according to the rules of ISO C for
an unsuffixed hexadecimal; <P>
<LI><CODE>~lit_unsigned</CODE> is the external identification of a
token that returns the integer type according to the rules of ISO
C for integers suffixed by U only; <P>
<LI><CODE>~lit_long</CODE> is the external identification of a token
that returns the integer type according to the rules of ISO C for
integers suffixed by L only. <P>
</UL>
<A NAME=S129>
<HR><H2>C.2  The Portability Table</H2>
The portability table is used by the checker to describe the minimum
assumptions about the representation of the integral types. It contains
information on the minimum integer sizes and the minimum range of
values that can be represented by each integer type.<P>
Two built-in portability tables are provided. The default reflects
the minimal requirements laid down in the ISO C standard. The 32-bit
portability table (specified by the passing the -Y32bit option to
tchk) reflects the implementation on most modern 32 bit machines.
These tables are shown below.<P>
<B>ISO/ANSI Minimum Requirements Portability Table (default)</B><BR>
<CENTER>
<IMG SRC="table2.gif">
</CENTER>
<P>
<B>32 bit Portability table (specified by -Y32bit option)</B><BR>
<CENTER>
<IMG SRC="table3.gif">
</CENTER>
<P>
The decimal integer associated with each of <EM>char_bits</EM>, <EM>short_bits
</EM>, <EM>int_bits</EM> and <EM>long_bits</EM> gives the minimum
number of bits in the representation of each integer type on all target
machines. For example, if <EM>int_bits</EM> is set to 32 the compiler
will perform its checks in the knowledge that the program will not
be used on a machine whose int types are represented by 16 bits although
they might be represented by 32 or 64 bits.<P>
The minimum integer ranges are deduced from the minimum integer sizes
as follows. Suppose b is the minimum number of bits that will be used
to represent a certain integral type, then:<P>
<UL>
<LI>For unsigned integer types the minimum range is [0, 2<SUP>b</SUP>-1];<P>
<LI>For signed integer types if <CODE>signed_range</CODE> is maximum
the minimum range is [-2<SUP>b-1</SUP>, 2<SUP>b-1</SUP>-1]. Otherwise,
if <EM>signed_range</EM> is symmetric the minimum range is [-(2<SUP>b-1</SUP>-1),
2<SUP>b-1</SUP>-1];<P>
<LI>For the type char which is not specified as signed or unsigned,
if <EM>char_type</EM> is signed then char is treated as signed, if
<EM>char_type</EM> is unsigned then char is treated as unsigned, and
if <EM>char_type</EM> is either, the minimum range of char is the
intersection of the minimum ranges of signed char and unsigned char.<P>
</UL>
<HR>
<P><I>Part of the <A HREF="../index.html">TenDRA Web</A>.<BR>Crown
Copyright &copy; 1998.</I></P>
</BODY>
</HTML>