Paul Eggert wrote: > a nonempty text file must end in a newline.
Yes, the definitions of "Text File" and "Line" in https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html say so. > > - fprintf (fp, "%u\n", (unsigned int) (((bits ^ (bits - 1)) + > > 1) >> 1)); > > + fprintf (fp, "%u", (unsigned int) (((bits ^ (bits - 1)) + 1) > > >> 1)); > > This sort of change relies on undefined behavior in POSIX. In the POSIX > shell, a command like A=$(B) requires B to output text I don't see that command substitution in general needs to output "text". https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_03 section 2.6.3 only mentions "the standard output of the command". When I write `cat conftest.out`, does conftest.out need to be a text file? In https://pubs.opengroup.org/onlinepubs/9699919799/utilities/cat.html I don't see this requirement. On the contrary: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html says "The standard utilities that have such restrictions always specify "text files" in their STDIN or INPUT FILES sections." and https://pubs.opengroup.org/onlinepubs/9699919799/utilities/cat.html says: "The input files can be any file type." So, 'cat' works with any input file. > To avoid this issue the program could use 'fopen (..., "wb")'. But using "wb" causes problems on z/OS [1]. > We could just leave things alone, as I don't know of any POSIXish > systems that would mishandle files lacking trailing newlines in this > situation. I remember the times, 20-30 years ago, when 'sed' would have problems with files that did not end in a newline. But that's long long ago. Bruno [1] https://lists.gnu.org/archive/html/bug-gnu-libiconv/2023-05/msg00002.html
