This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Help : File does not end with newline


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]