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

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 10.02.2025 01:57, Keith Thompson wrote:

[...]

The above describes how a text stream looks to a C program.  The
external representation can be quite different, with transformations
to map between them.

>
(Concerning this thread; I'm anyway operating on custom data files
in plain text format, so I'm less concerned about how "C" compilers
expect their "C" source.)

The requirements for text streams are distinct from the requirements
for C source files.  For example, you might have a cross-compiler
where C source files follow the rules of the OS where the compiler
runs, and text files processed via stdio follow the rules of
the target system.  And a C compiler might not use stdio to read
source files.  It might not even be implemented in C.

In particular, the standard has this specific requirement for source
files (this is from the "Translation phases" section):

    A source file that is not empty shall end in a new-line
    character, which shall not be immediately preceded by a backslash
    character before any such splicing takes place.

(This is in translation phase 2; any new-line characters might be
the result of a transformation during phase 1.)

So a non-empty file not ending in a new-line character might be a
valid text file for use with stdio, but is not a valid C source file.
On the other hand, the mapping described in translation phase 1
might add a new-line character to such a file, so a conforming
compiler could accept such a source file without complaint.

Of the compilers I've tried, gcc and tcc quietly accept a source
file with no trailing newline, and clang rejects it with the right
options (-std=c?? -pedantic-errors).

[...]

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.
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.

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.  I found a possible
solution, but I haven't bothered using it since I'm not currently
dealing with such files.

<https://vi.stackexchange.com/q/39297/2380>

This is already off-topic, so I won't even mention tabs vs. spaces.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */