Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: while loop vs do while loop reading from the file issue Date: Tue, 13 Dec 2016 17:56:32 -0800 Organization: None to speak of Lines: 63 Message-ID: References: <52f1c174-6af1-4fda-9ff8-a5e2cf507b5f@googlegroups.com> <87d1gyw8s6.fsf@bsb.me.uk> <87inqpucmw.fsf@bsb.me.uk> <87fultqnuz.fsf@bsb.me.uk> <87bmwgpxbs.fsf@bsb.me.uk> <87mvg0o6hk.fsf@bsb.me.uk> <87y3zj8j94.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="f4d023dc7368ee832f7340f59496ea26"; logging-data="11795"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/va+6/mXBnV/jVeIRQhAyV" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:QcLlcFVyP1xPtIMcRloHTOs7BLI= sha1:+2Wu9zRlkH3PITRCppnrOfy9SpY= Xref: csiph.com comp.lang.c:99301 BartC writes: > On 14/12/2016 00:08, Ben Bacarisse wrote: >> BartC writes: [...] >>> p = (buffer+n)-1; >> >> Why the brackets? > [...] > And I just noticed you called them brackets. I think I'll do that from > now on too. A lot easier to type.) Calling these: () "brackets" seems to be UK usage. In the US, the usual terms are (parentheses), [brackets], {braces}. If ease of typing is an issue, you might consider "parens". In any case, please think about the possibility of ambiguity -- for example you might use [square brackets] and {curly braces}. And perhaps (round brackets) if you choose to use that word. [...] >> I'll put aside the fact that you are trying to handle CRLF yourself >> (that's another massive thread where all other C programmers are doing >> it wrong), but (a) why 10 and 13 rather than character constants? > > Sometimes I define cr and lf, and sometimes I don't. For example, I > might use 13 and 10 for a quick test, then the code becomes permanent. You don't need to define identifiers, just use the standard character constants '\r' and '\n'. > >and > > why do you remove CR characters that are /not/ part of the line ending? > > I don't allow for individual CR or LF within a line. > > I expect newline sequences to be either CR/LF or LF (I no longer support > CR and have never come across LF/CR). > > CR/LF read under Windows I think converts to LF in the buffer. Under > Linux as CR/LF. > > LF read under Linux is just LF; under Windows ... I'm not sure but fgets > seems to have no trouble reading separate lines using just LF. A line ending sequence, whatever it is, is translated to a single '\n' character on input from a text stream. It's not surpising that on Windows, and untranslated LF character (not necessarily recognized explicitly as an end-of-line marker) would appear as '\n'. > Anyway I get rid of all these controls where I can, but I'm not going to > search the entire buffer for stray CRs. My advice: Treat text as text. If you need to read text in some foreign format, translate it before feeding it to your program. -- 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"