Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: "C's Biggest Mistake" Date: Thu, 05 Apr 2018 13:39:22 -0700 Organization: None to speak of Lines: 56 Message-ID: References: <9c7013a2-17bd-4f94-a378-1c45151d0d45@googlegroups.com> <6zpxC.75432$bz1.69868@fx01.iad> <%6sxC.621528$Ml.294897@fx24.am4> <85txC.105783$q15.11321@fx34.iad> <78430698-e312-4729-a952-ff6f968cf5ba@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="7bf2a82357868b78051038e61a1f9d6f"; logging-data="3971"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/AjFeele50qZEwzRDjQm+x" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:VODvZROSsrz/kZeTB/1rtP4Bx1s= sha1:98frqJfhtuIc4YZPRK+5ebjGCt4= Xref: csiph.com comp.lang.c:128804 supercat@casperkitty.com writes: > On Thursday, April 5, 2018 at 1:23:20 PM UTC-5, Keith Thompson wrote: >> bartc writes: >> [...] >> > With C, the \ exists in part of source which is the domain of the >> > comment text. \ characters can exist in // comments without forming line >> > continuation. A \ becomes a line continuation only if there are zero or >> > more spaces or tabs between the \ and the newline. >> >> N1570 5.1.1.2, translation phase 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. >> >> My understanding is that "immediately followed" means there can't be any >> spaces between the backslash and the new-line. gcc and clang apparently >> disagree with me on this point. > > The Standard does not require that the source text stream use the same > representation as any physical file from which it is read. Indeed, a > systems that use fixed-length or length-prefixed records would be required > to add a translation layer, as would systems that use CR or CR+LF as a line > delimiter. An implementation that documents that any number of blanks which > are followed by a CR and/or LF will be together regarded as a new line would > be required to regard blackslash+blank+CR+LF as a newline that is preceded > immediately by a backslash. Yes, in phase 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. [...] The documentation for the GNU C preprocessor says: If there is white space between a backslash and the end of a line, that is still a continued line. However, as this is usually the result of an editing mistake, and many compilers will not accept it as a continued line, GCC will warn you about it. It's hard to tell whether this is saying that treating white space is part of the "implementation-defined manner" referred to in the standard, or whether the authors believe that the standard requires that white space to be ignored. I suspect the latter, since it's not described as a mapping or transformation. Do you know of an implementation that documents that blanks between a backslash and new-line are discarded? -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"