"Nitin Bhardwaj" <ni*************@hotmail.com> wrote in message
news:17**************************@posting.google.c om...
Hi all,
Can anyone please provide a code snippet containing a construct that
is syntactically correct but symantically
semantically
wrong.
int main()
{
int i;
int i;
return 0;
}
Also the grammar of the C language is applied at what stage of the
compilation?
When syntax and semantics are analyzed.
AFAIK following are the stages -
Step I : Lexical Analysis ( Tokenizing > Parsing )
Step II : Syntactical Analysis
Step III : Symantic Analysis
Step IV : Translation of the unit.
I want to know actually what is involved in the synamtic analysis step
semantic
!
The standard does not define a 'semantic analysis step'. It defines
eight 'phases of translation'. The definition of Phase 7 states
(among other things) "tokens are syntactically and semantically analyzed",
but does not specifically require a particular order or method.
The standard does define semantics for lexical elements (i.e. tokens
and preprocessing-tokens), and further semantics for subsets of lexical
elements, such as keywords and identifiers.
================================================== ======================
ISO/IEC 9899:1999 (E)
5.1.1.2 Translation phases
1 The precedence among the syntax rules of translation is specified by
the following phases (5)
1. Physical source file multibyte 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 sequences are replaced by corresponding
single-character internal representations.
2. Each instance of a backslash character (\) immediately followed
by a new-line character is deleted, splicing physical source
lines to form logical source lines. Only the last backslash on
any physical source line shall be eligible for being part of
such a splice. A source file that is not empty shall end in a
new-line character, which shall not be immediately preceded by
a backslash character before any such splicing takes place.
3. The source file is decomposed into preprocessing tokens (6) 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 sequence of white-
space characters other than new-line is retained or replaced by
one space character is implementation-defined.
4. Preprocessing directives are executed, macro invocations are
expanded,
and _Pragma unary operator expressions are executed. If a character
sequence that matches the syntax of a universal character name is
produced by token concatenation (6.10.3.3), the behavior is
undefined.
A #include preprocessing directive causes the named header or source
file to be processed from phase 1 through phase 4, recursively. All
preprocessing directives are then deleted.
5. 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
(wide) character.(7)
6. Adjacent string literal tokens are concatenated.
7. White-space characters separating tokens are no longer significant.
Each preprocessing token is converted into a token. The resulting
tokens are syntactically and semantically analyzed and translated as
a translation unit.
8. All external object and function references are resolved. Library
components are linked to satisfy external references to functions
and
objects not defined in the current translation. All such translator
output is collected into a program image which contains information
needed for execution in its execution environment.
5) Implementations shall behave as if these separate phases occur, even
though
many are typically folded together in practice.
(6) As described in 6.4, the process of dividing a source file's
characters
into preprocessing tokens is context-dependent. For example, see the
handling of < within a #include preprocessing directive.
(7) An implementation need not convert all non-corresponding source
characters
to the same execution character.
================================================== ======================
-Mike
