Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: #include /* comment legal? */ Message-ID: <6545@brl-smoke.ARPA> Date: Sat, 10-Oct-87 00:24:34 EDT Article-I.D.: brl-smok.6545 Posted: Sat Oct 10 00:24:34 1987 Date-Received: Mon, 12-Oct-87 02:54:23 EDT References: <169@decvax.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 27 In article <169@decvax.UUCP> minow@decvax.UUCP (Martin Minow) writes: >May a comment follow the file specifier in an #include statement? Yes. The only constraint is that "/*" embedded within the header or file name is considered to yield "undefined" behavior. There is no problem with a comment outside the name. >While comments are syntactically "white-space characters", the Standard >specifically states that only space and horizontal-tab may appear within >a preprocessing statement (sec 3.7.1, p 76, line 34-36). That's because, as explained under 2.1.1.2 Translation Phases, each comment has already been converted to one space character at this point. >For that matter, may a comment appear in any p.p. statement such as: > #define BEAUTY TRUE /* All you need to know */ Yes, of course. >What is the modtivation for the "only space and tab" constraint? There didn't seem to be any reason to require implementations to support embedded vertical-motion whitespace or backspaces in preprocessing directives, and it was easy to envision possible problems in some situations. If you think this needs to be generalized, it would behoove you to come up with convincing reasons.