Am 17.12.2025 um 20:35 schrieb Michael Sanders:
Sigh, here we go...That's not so important because it's about the general principle.
Everything in every thread I've read from you is faster, better,
& you finished in two hours & yet here you are.
*Very rich* Bontia. Thank you, but as others have pointed out:
This is a C newsgroup, not a C++ newsgroup.
Writing it in C would only be slightly different.
static const char phrase[] = "I dont want or care about C++...";
printf("%s\n", phrase);
So, why not post C versions? Or, I guess it would be extended C.Becaue it's easier to write safe code in C++.
Am 18.12.2025 um 13:49 schrieb bart:
So, why not post C versions? Or, I guess it would be extended C.
Becaue it's easier to write safe code in C++.
Some people here thought they could develop efficient code for that.Becaue it's easier to write safe code in C++.Wouldn't it be easier still to just not post at all?
A text file is supposed to end with a '\n'
This brings back memories, most of them fond.
From the glibc Reference Manual:
rCLThe distinction between text and binary streams is only meaningful
on systems where text files have a different internal
representation. On Unix systems, there is no difference between the
two; the rCybrCO is accepted but ignored.rCY
On Sun, 7 Dec 2025 19:01:02 +0000, Richard Harnden wrote:
A text file is supposed to end with a '\n'
PDF files end with that. The object index comes at the end, and each
index entry is fixed in length and ends with \015\012.
But the spec makes it very clear that PDF files are not supposed to be treated as text files.
The best you can do, is for the PDF to be entirely text except for
some bytes near the top (second line). It's not exactly clear what
they do ...
.. with CRLF, NEL line terminators
Also, the only difference between XML 1.0 and XML 1.1 is that the
latter adds NEL as a permitted line terminator.
I tested the "find.exe" in Cygwin64 and it did not finish. I used
Process Monitor to see what it was doing, and there was a lot of
registry activity. (There should not be registry activity by
find.exe or file.exe )
I tried the file.exe command and it didn't provide output and the
machine hung. My machine never hangs. It's a model citizen. Windows
Defender did not trip. An offline scan with Windows Defender did not
find anything.
On Fri, 12/26/2025 10:13 PM, Lawrence DrCOOliveiro wrote:
On Sun, 7 Dec 2025 19:01:02 +0000, Richard Harnden wrote:
A text file is supposed to end with a '\n'
PDF files end with that. The object index comes at the end, and each
index entry is fixed in length and ends with \015\012.
But the spec makes it very clear that PDF files are not supposed to be
treated as text files.
The best you can do, is for the PDF to be entirely text except for
some bytes near the top (second line). It's not exactly clear what they do, but I've seen at least one document that misses the binary line. That binary-thing could be a hash over the document.
On Mon, 8 Dec 2025 13:51:49 +0100, Bonita Montero wrote:No, MacOS, not macOS; the latter is "MacOS" since macOS X.
From the glibc Reference Manual:However, you need to distinguish the two if you want, like Python
rCLThe distinction between text and binary streams is only meaningful
on systems where text files have a different internal
representation. On Unix systems, there is no difference between the
two; the rCybrCO is accepted but ignored.rCY
does, to be able to have a rCLuniversal newlinerCY mode, where you can correctly handle line breaks in files written on any of the three main platform families: *nix/Unix, Windows, and macOS.
This is such a useful idea IrCOm surprised no one has suggested that C
should offer the option.
However, you need to distinguish the two if you want, like PythonNo, MacOS, not macOS; the latter is "MacOS" since macOS X.
does, to be able to have a rCLuniversal newlinerCY mode, where you can
correctly handle line breaks in files written on any of the three main
platform families: *nix/Unix, Windows, and macOS.
Your assertion is contrary to that operating system vendor's own
stance and branding.
https://www.apple.com/os/macos
Am 27.12.2025 um 06:51 schrieb Lawrence DrCOOliveiro:
On Mon, 8 Dec 2025 13:51:49 +0100, Bonita Montero wrote:
From the glibc Reference Manual:
rCLThe distinction between text and binary streams is only
meaningful on systems where text files have a different internal
representation. On Unix systems, there is no difference between
the two; the rCybrCO is accepted but ignored.rCY
However, you need to distinguish the two if you want, like Python
does, to be able to have a rCLuniversal newlinerCY mode, where you can
correctly handle line breaks in files written on any of the three main
platform families: *nix/Unix, Windows, and macOS.
This is such a useful idea IrCOm surprised no one has suggested that C
should offer the option.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 54 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 12:32:20 |
| Calls: | 742 |
| Files: | 1,218 |
| D/L today: |
2 files (2,024K bytes) |
| Messages: | 183,176 |
| Posted today: | 1 |