Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: Programming exercise/challenge
Date: Sun, 27 Dec 2020 05:16:42 -0800
Organization: A noiseless patient Spider
Lines: 68
Message-ID: <86pn2vwfr9.fsf@linuxsc.com>
References: <86wnxwkyol.fsf@linuxsc.com> <871rg2rffu.fsf@bsb.me.uk> <86v9dehts2.fsf@linuxsc.com> <87360hq0si.fsf@bsb.me.uk> <1bpzH.151400$zz79.48736@fx17.ams4> <86lfe779k6.fsf@linuxsc.com> <lF3AH.20085$hz6.8960@fx39.iad> <865z4ryphr.fsf@linuxsc.com> <877dp79cl9.fsf@nosuchdomain.example.com> <du8FH.44799$R82.5801@fx46.iad>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="7428659b5bf23ec7739a8c9d5f9c9404"; logging-data="12195"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19VHJ38I38gPW1sI8eKCKbtDvmza5/ufpM="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:C146dVo/hV7uEaYRA2VC7ybLt6s= sha1:ywh1ETXadwt0t7ib5RAvd0m0U6g=
Xref: csiph.com comp.lang.c:157814

Richard Damon <Richard@Damon-Family.org> writes:

> On 12/24/20 3:24 PM, Keith Thompson wrote:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>
>>>> On 12/9/20 1:55 AM, Tim Rentsch wrote:
>>>>
>>>>> Bart <bc@freeuk.com> writes:
>>>>> [...]
>>>>>
>>>>>> The spec did say to make your own decisions on corner cases.
>>>>>
>>>>> Corner cases are meant to be only for input that the C
>>>>> standard specifies as undefined behavior.
>>>>
>>>> or implementation defined or unspecified behavior, like the
>>>> \<space><newline> case.
>>>
>>> No, I meant what I said.  Furthermore any compiler that
>>> accepts \<space><newline> as a line continuation is not
>>> conforming, as I have explained else-thread.
>>
>> I thought I had seen (and perhaps even made) an argument that 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.
>>
>> could include removing trailing spaces.  I admit it's a bit of a
>> stretch of the meaning of "mapped".
>>
>> Aside from what the standard actually says, I certainly think it's more
>> convenient to be able to ignore spaces at the end of a line following a
>> \ character.  Treating backslash+space at the end of a line differently
>> than backslash at the end of a line is awkward, even if it's conforming.
>> I'd like to see a modification to phase 1 saying that white space
>> between \ and the end of a line is discarded.
>
> The big part of the issue is that some system don't use \n or anything
> like it to terminate lines, but store text files as fixed length records
> which are space filled.  In such an environment, it would be very
> inconvinent, if not impossible to make the \ the very last character of
> the line (different parts of the system might use different length
> possible lines, so file moved to a longer system would no longer be at
> the end, and the need to have the \ at the end would make it likely
> cause an error if you tried to move it to a short length system.
>
> The C Standard makes several concessions to support such systems, like
> the possible loss of spaces at end of text lines in files, and I thought
> it was clarified that this included similar options to phase 1.
>
> So yes, if phase 2 sees \<space><newline> it should not interpret that
> as a line continuation, but phase 1 might convert <space><newline> to
> just be <newline> under the clause of
>
> (introducing new-line characters for end-of-line indicators)
>
> by defining the 'end-of-line indicator' to be an arbitrary and optional
> number of white spaces followed by a newline character.

Presumably whatever rule the compiler is using is the same as the
rule for text streams in the environment of the decommenting
program.  It's pointless to compare cases where these two rules
are different, like what I said in my earlier response elsethread.