🚀 go-pugleaf

In article <41sjrp$8kb@newshost.lanl.gov>, tanmoy@qcd.lanl.gov (Tanmoy Bhattacharya) writes:
|> In article <41si6s$4qs@lyra.csx.cam.ac.uk>, nmm1@cus.cam.ac.uk (Nick
|> Maclaren) writes: 
|> <snip>
|> |> This is the usual reason, but be warned that SOME compilers will parse
|> 
|> The SOME above refers to every ANSI compliant compiler. The preprocessor
|> works after the text has been `tokenized' Thus, you can skip over `The quick brown fox.' even if you have defined no
|> macros (and then it is clear that it cannot be `syntactically' valid C code),
|> and yet you cannot skip over `My father's house' because the unmatched single
|> quote leads to problems with parsing the text lexically.

This was not what I was referring to, actually.  But see later.

|> |> (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
and 3.8 on 'semantics').

|> |> 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
lead to undefined behaviour, and conforming implementations are NOT
require to diagnose this (in general).

A more subtle horror occurs in unmentioned behaviour (i.e. aspects
that are not mentioned at all in the standard).  For example, using
a character that exists in the source but not execution character
set in a string constant.


Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679