Re: Buffer contents well-defined after fgets() reaches EOF ?

On 10.02.2025 05:37, Keith Thompson wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> 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.

 
<https://vi.stackexchange.com/q/39297/2380>
 
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