Symantic - syntactic

[Nitin Bhardwaj]

Hi all,

Can anyone please provide a code snippet containing a construct that
is syntactically correct but symantically wrong.

Also the grammar of the C language is applied at what stage of the
compilation?
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
!

Thanx in advance..

 

[Vijay Kumar R Zanvar]

Hi all,

Can anyone please provide a code snippet containing a construct that
is syntactically correct but symantically wrong.

I may be wrong in the following in the following, but let's try.

{
int *p;
*p = 10;
}

is syntactically correct, but sematically wrong. Storing 10 into an
uninitialized location has got nothing to do with the syntax. Whereas, it is
semantically wrong because it has no meaning.

Also the grammar of the C language is applied at what stage of the
compilation?

I believe at syntax analysis. I think semantic analysis is not required to
be performed by a compiler.

 

[Jim]

I may be wrong in the following in the following, but let's try.

{
int *p;
*p = 10;
}

is syntactically correct, but sematically wrong. Storing 10 into an
uninitialized location has got nothing to do with the syntax. Whereas, it is
semantically wrong because it has no meaning.


I believe at syntax analysis. I think semantic analysis is not required to
be performed by a compiler.

I would say, broadly speaking, that it's the difference between the
compiler emitting an error, because the code is syntactically wrong,
or a warning, because the code might be wrong, semantically.

Jim

 

[Mike Wahler]

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

 

[Mike Wahler]

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.

I meant to add: also note footnote (5).

-Mike

 

[Kenneth Brody]

Hi all,

Can anyone please provide a code snippet containing a construct that
is syntactically correct but symantically wrong.

[...]

int compare(int x, int y)
{
if ( x = y ) /* should be "==" */
return(0);
else if ( x < y )
return(-1);
else
return(1);
}

I suppose the following could, technically, qualify as well:

i = i++;

 

[Dave Vandervies]

Hi all,

Can anyone please provide a code snippet containing a construct that
is syntactically correct but symantically wrong.

--------
int foo(int i)
{
/*Add 17 to i*/
j+=42;
return i;
}
--------

Also the grammar of the C language is applied at what stage of the
compilation?
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
!

The grammar is used for syntactic analysis, which you have at step II.
(But you're missing preprocessing, which happens between tokenizing and
parsing (actually between tokenizing-for-preprocessing and retokenizing-
for-parsing), and parsing belongs with the syntactic analysis, not
lexical.) The C standard defines various "translation phases" that
I'm not familiar with but my recollection of which doesn't match your
list of steps here, so using these terms in comp.lang.c may cause some
slight confusion.

The result of the syntactic analysis is a parse tree that represents
the structure of the code, and the semantic step takes this parse tree
and decides "what it means". (F'rexample, the parse tree for 'i+=42'
will indicate that it's an addition-assignment operator with arguments
'i' (which is an identifier) and '42' (which is an integer constant),
and the semantic analysis will look up what exactly the identifier
'i' refers to and check that it's valid in that scope. It's up to the
programmer to make sure that it's actually meaningful and consistent
with what should be happening.)

This is more of a compiler question than a C question. comp.compilers
comes to mind as a possibly better place to ask for more details.


dave

 

[Minti]

Hi all,

Can anyone please provide a code snippet containing a construct that
is syntactically correct but symantically wrong.

Just a textbook example but consider

int a[10];
a[(float)5] = 23;

Will be correct syntactically but semantically it is incorrect. Also
syntactically

a[10] is correct syntactically but semantically it is wrong, and the
compiler _might_ give you a diagnostic.

Then

(void) 23 + 23;
(void*) p_v + 23;

+ Plethora of others.

Also the grammar of the C language is applied at what stage of the
compilation?
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
!

Thanx in advance..

Sort of, but if you want to know really what they are consult the
standard, if you want to know how they are implemented pick up the
Dragon[1].


[1] Compilers Tools and Techniques by Aho, Ullman and Sethi [The above
example is from this book only]

 

[Minti]

I may be wrong in the following in the following, but let's try.

{
int *p;
*p = 10;
}

is syntactically correct, but sematically wrong. Storing 10 into an
uninitialized location has got nothing to do with the syntax. Whereas, it is
semantically wrong because it has no meaning.


I believe at syntax analysis. I think semantic analysis is not required to
be performed by a compiler.

Then you think wrong. Read your own example or examples posted by others.

 

[Mike Wahler]

Hi all,

Can anyone please provide a code snippet containing a construct that
is syntactically correct but symantically wrong.

[...]

int compare(int x, int y)
{
if ( x = y ) /* should be "==" */

This is both syntactically and semantically correct from
a language standpoint. However it might not be what the
coder meant.

return(0);
else if ( x < y )
return(-1);
else
return(1);
}

I suppose the following could, technically, qualify as well:

i = i++;

I think that's a constraint violation, not a semantic violation.
It's certainly not a syntax error.

-Mike

 

[ozbear]

Hi all,

Can anyone please provide a code snippet containing a construct that
is syntactically correct but symantically wrong.

char *fmt = "%s";
printf(fmt,943.12);

or even...

printf("%s",943.12);

... if one's compiler doesn't diagnose the mismatch for constant
format strings.

Oz

 

[Peter Nilsson]

I think that's a constraint violation, not a semantic violation.

The opposite. It voilates semantics in the sense that no semantics are defined for the
expression. However, it does not obviously violate a constraint. The most applicable one
would be 6.5.2.4p1...

The operand of the postfix increment or decrement operator shall
have qualified or unqualified real or pointer type and shall be
a modifiable lvalue.

Note: 6.5p2 is not a constraint.

 

[Dan Pop]

Can anyone please provide a code snippet containing a construct that
is syntactically correct but symantically wrong.

Yup, any program bug qualifies as such. Arbitrary example:

int main()
{
int i, j = i; /* i has an indeterminate value */
}

Dan

 

[pete]

Hi all,

Can anyone please provide a code snippet containing a construct that
is syntactically correct but symantically wrong.

int pointer = NULL;
*pointer = 0;

 

[Allin Cottrell]

int pointer = NULL;
*pointer = 0;

Smoking material?
error: invalid type argument of `unary *'.

Allin Cottrell

 

[pete]

Smoking material?

Untested code.
I usually get caught whenever I post untested code.

error: invalid type argument of `unary *'.

int *pointer = NULL;
*pointer = 0;

 

[Mike Wahler]

Untested code.
I usually get caught whenever I post untested code.


int *pointer = NULL;
*pointer = 0;

But there's nothing wrong with that code. It's syntactically
correct, and its behavior is well defined.

Perhaps you meant the second statement to be simply:

*pointer;

which would be a semantic error.

-Mike

 

[pete]

But there's nothing wrong with that code. It's syntactically
correct, and its behavior is well defined.

Perhaps you meant the second statement to be simply:

*pointer;

which would be a semantic error.

No. I got it right that time.
*pointer = 0;
attempts to assign a value of 0 to an int type object,
pointed to by pointer, but pointer doesn't point to an object.

 

[Mike Wahler]

No. I got it right that time.
*pointer = 0;
attempts to assign a value of 0 to an int type object,
pointed to by pointer, but pointer doesn't point to an object.

You're right. I must have looked at that cross-eyed the
first time.

-Mike