This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: EOF character in parser
- From: "Zack Weinberg" <zack at codesourcery dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: wilson at specifixinc dot com, gagneet at acmet dot com, gcc at gcc dot gnu dot org
- Date: Mon, 05 Jan 2004 17:53:34 -0800
- Subject: Re: EOF character in parser
- References: <1072501124.14935.ezmlm@gcc.gnu.org><006a01c3cd48$55e00530$9900a8c0@GAGNEET><3FFA0A09.8000104@specifixinc.com><200401060115.i061FSfr025053@greed.delorie.com>
DJ Delorie <dj@redhat.com> writes:
>> This sounds like a C library problem. The C library should indicate
>> end-of-file when it sees a 0x1a character. Gcc should not need to
>> check for end-of-file characters, as it uses system calls like read
>> that do it for us.
>
> Note that gcc disables that functionality in libc, so it actually
> does handle the 0x1a itself.
I don't know if this is true or not. cpplib passes O_BINARY to open()
on systems that define that constant, but the comments in cppfiles.c
claim that this only disables translation of \r\n style line breaks.
There is no special handling of 0x1a in cpplib.
The Fortran, Java, and Ada front ends don't use cpplib so I don't know
what they do.
> Note also that gcc normally uses mmap() to read the file, not read().
No longer true; it caused more trouble than it was worth.
zw