🚀 go-pugleaf

In article <41urae$15e@lyra.csx.cam.ac.uk>, nmm1@cus.cam.ac.uk (Nick
Maclaren) writes: 

<snip: Talking about #if 0 ... #endif to exclude text.>
|> |> |> (or partially parse) some of the excluded text.  You should
therefore 
|> |> |> not use this trick to exclude syntactically invalid C.  The reason
for 
|> |> 
|> |> It can be syntactically invalid C: it must not be _lexically_ invalid C.
|> 
|> This is true, in general, but is not what the standard says (see 2.1.1.3

5.1.1.3 `Diagnistics' says that a conforming implementation must produce at
least one diagnostic message for every _translation unit_ that contains a
violation of any syntax rule or constraint. (emphasis mine) TC 1 corrected it
to say that the diagnostic is required even if there is undefined and
implementation defined behaviour occurring simultaneously.

5.1.1.1 `Program structure' defines that a translation unit is a source file
with all headers and source files included via #include, _less_ any source
lines skipped by any of the conditional inclusion preprocessing directives.

So, where do you find that syntactically invalid C cannot be skipped? (By the
way, the fact that lexically invalid C cannot be skipped is obvious from
5.1.1.2 `Translation phases'.)

|> and 3.8 on 'semantics').

6.8 `Preprocessing directives' semantics just states that the implementation
can process and skip sections of source files, include other source files,
and replace macros. 

I fail to see the relevance of this to the current discussion.

|> 
|> |> |> this problem is that the standard is unclear in this area.
|> |> 
|> |> Why do you claim the _standard_ is unclear in this area? Which standard
are 
|> |> you talking about? There does not seem to be any hint of lack of
clarity  in
|> |> the ANSI standard!
|> 
|> Where shall I start?
|> 
|> 2.1.1.3 refers to 'any syntax rule or constraint', but there is no
|> definition of which rules are syntactic.  For example, many rules

Are you complaining that the standard should have said `a rule stated in a
"syntax" or "constraint" section' rather than `a syntax rule or constaint'.

I think the meaning is obvious: the standard is absolutely clear about which
rules are syntax rules and which are not: it puts the former in the syntax
section, and the latter outside it :-) Similarly it states constraints under
the heading of constraints, and non-constraints outside it.

|> lead to undefined behaviour, and conforming implementations are NOT
|> require to diagnose this (in general).

3.16 `undefined behaviour' actually makes this more clear: conforming
implementations are not restricted in any way once they meet undefined
behaviour (except so far as specified in 5.1.1.3 TC1).

|> 
|> A more subtle horror occurs in unmentioned behaviour (i.e. aspects
|> that are not mentioned at all in the standard).  For example, using

3.16 `undefined behaviour' last sentence makes clear that there is no
difference between this and other kinds of undefined behaviour.

|> a character that exists in the source but not execution character
|> set in a string constant.

Your example is bad: this is explicitly mentioned in the standard as
implementation-defined (and 3.16 makes it clear that implementation-defined
behaviour is _not_ undefined behaviour)

6.1.4 `String literals' Description says that the "same considerations apply
to each element of the sequence in a character string literal or a wide
character string literal as if it were in an integer character constant or a
wide character constant ...".  6.1.3.4 `Character constants' semantics says
that "The value of an integer character constant containing more than one
character, or containing a character or escape sequence not represented in
the basic execution character set, is implementation-defined." 

Cheers
Tanmoy
-- 
tanmoy@qcd.lanl.gov(128.165.23.46) DECNET: BETA::"tanmoy@lanl.gov"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87544-0285,USA H:#3,802,9 St,NM87545
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: 1 (505) 665 3003   voice: 1 (505) 665 4733    [ Home: 1 (505) 662 5596 ]