This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Help : File does not end with newline
- To: gcc at gcc dot gnu dot org
- Subject: Re: Help : File does not end with newline
- From: kaih at khms dot westfalen dot de (Kai Henningsen)
- Date: 30 Sep 2001 22:54:00 +0200
- Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
- Organization: Organisation? Me?! Are you kidding?
- References: <20010930165842.2ACA6F2B7A@nile.gnat.com>
dewar@gnat.com wrote on 30.09.01 in <20010930165842.2ACA6F2B7A@nile.gnat.com>:
> <<Not directly. But Windows does seem to have a plethora of broken editor
> software. Try to open/save this file in another source code editor, such
> as emacs or even Windows Notepad.
> >>
>
> Note that it is entirely within normal Windows standards for the last
> character in the file to be 0x1A, you can even argue that this is the
> standard format, so many editors in Windows put this character there,
> but typical Unix software is not setup to properly handle this end
> of file character on Windows, so perhaps that is the problem.
No, this is false. Standard Windows textfiles do not contain a terminating
0x1A.
That idea originated in CP/M, where file sizes were only recorded in full
128-byte blocks, and thus text files needed a separate end marker, and it
was still sort-of valid in MS-DOS because there were so many programs
ported over from CP/M.
However, I can't remember seeing a Windows-based editor that did this, or
a Windows-based textfile that had that 0x1A.
It is true, however, that various Windows libc variants tend to get upset
at seeing a 0x1A on input, telling upper layers they saw EOF. These days,
this should probably regarded as a bug.
MfG Kai