>> info groff gives semantics for including nonempty files that don't end
>> with newline. Such files violate the Posix definition of text file.
In fact, nowhere in the term "text file" defined (or used — search for it) in the POSIX standard. The problem is that at the same time, ANSI C was being defined in the early 1980s The DOS weenies wanted to support the silly two characters line terminations and old notion of a structured "text file" which PC/MS-DOS had inherited from the DEC and IBM OS's of 1960s and what IBM has called "access methods" in the old days (in UNIX everything is just a stream of bytes thank you or in Multics, everything is segment). The UNIX folks on the C committee were very much against adding the support — which Lattice C for MS-DOS had added at the time but happened to be the most popular C compiler for the DOS target and the number of user of the compiler was growing extremely rapidly. They were also pushing for things like the near and far keywords. It was quite a fight in the C community. (It was one of the additions that caused Dennis to quip: "When I read commentary about suggestions for where C should go, I often think back and give thanks that it wasn't developed under the advice of a worldwide crowd."3.164 FileAn object that can be written to, or read from, or both. A file has certain attributes, including access permissions and type. File types include regular file, character special file, block special file, FIFO special file, symbolic link, socket, and directory. Other types of files may be supported by the implementation.....3.317 Regular File
A file that is a randomly accessible sequence of bytes, with no further structure imposed by the system.
The key point in the highlighted text in ANSI C is that it does not require it. A problem in the ANSI C standard is that does >>use<< the term "text file" although ANSI C never really defines what one is (and probably could not because of the fight - UNIX would have said -- nope -- no structure required. ANSI C does say in:5.2.1 Character sets.... The representation of each member of the source and execution basic character sets shall fit in a byte.In both the source and execution basic character sets, the value of each character after 0 in the above
list of decimal digits shall be one greater than the value of the previous. In source files, there shall
be some way of indicating the end of each line of text; this International Standard treats such an
end-of-line indicator as if it were a single new-line character. In the basic execution character set,
there shall be control characters representing alert, backspace, carriage return, and new line. If any
other characters are encountered in a source file (except in an identifier, a character constant, a string
literal, a header name, a comment, or a preprocessing token that is never converted to a token), the
behavior is undefined.
The whole compromise was that you did not have to use termination of type. If the concept of a 'textfile" is local to the implementation. UNIX folks get to keep doing things as they did before, so if you used fopen with "r" or "w" its up to the program to worry about the format of the file "access modes" from the 1960s were not needed.7.21.2 Streams...Environmental limits
An implementation shall support text files with lines containing at least 254 characters, including
the terminating new-line character. The value of the macro BUFSIZ shall be at least 256.