Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Janis Papanagnou Newsgroups: comp.lang.c Subject: Re: Buffer contents well-defined after fgets() reaches EOF ? Date: Mon, 10 Feb 2025 07:08:22 +0100 Organization: A noiseless patient Spider Lines: 55 Message-ID: References: <87y0yepqg1.fsf@nosuchdomain.example.com> <87lduepg8h.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Injection-Date: Mon, 10 Feb 2025 07:08:27 +0100 (CET) Injection-Info: dont-email.me; posting-host="7ae7436750940773d2334410c5fdf1e5"; logging-data="1157996"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19e9bKu3eu0T7QUDOLMwzoD" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 Cancel-Lock: sha1:sWsH3muCCLk1PEhCSxsNdBA6lkU= X-Enigmail-Draft-Status: N1110 In-Reply-To: <87lduepg8h.fsf@nosuchdomain.example.com> Bytes: 3710 On 10.02.2025 05:37, Keith Thompson wrote: > Janis Papanagnou writes: > >> The most extreme context I had worked in was a company that allowed >> (for every employee) a free choice of used computer technology; that >> led to program text files that literally had all the inconsistencies. >> Since many files were edited by different folks there where all sorts >> of line terminators mixed even in the same one file, and there either >> were complete last lines or not. The (some?) IDEs used were tolerant >> WRT line terminators and their mixing. Other tools reacted sensibly. >> The first thing I've done was to write a "C" tool to detect and fix >> these sorts of inconsistencies. > > Been there, done that. There seems to be a tendency in the Windows > world to create text files with no terminator on the last line. Yep. > In some cases I've been able to translate the source files to a > consistent format. In others, doing so would have created huge > diffs in the source control system, so I left well enough alone. Yes, that is what you buy with a fix. But it pays, IME. What I had done was to provide scripts to automate the transformation, I did a short-term code freeze on a whole project, transformed the data, and since that point we had a consistent base. The good thing was that the single CR terminators (old Apple/Macs, pre OS-X) were only in older code. And the handling of LF vs. CR-LF was okay once that the script streamlined the data, either converting all to LF, or, to keep any conistent variant (whether it was LF or CR-LF). > > My preferred editor, vim, handles files with either LF or CRLF line > endings gracefully, but if there's a mix it shows "^M" at the end of > each line that has a Windows-style CRLF ending. Yes. With the change I described we got rid of this issue. > I found a possible > solution, but I haven't bothered using it since I'm not currently > dealing with such files. Same here. For me it was just a historic little episode. > > > > This is already off-topic, so I won't even mention tabs vs. spaces. But as Vim users we don't have any issues here; as long as the indentation is _visibly_ consistent we can fix any tab/space-mix on the fly and easily with Vim. Janis