This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Some more fortran safe-ctype & cleanups
- To: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Subject: Re: Some more fortran safe-ctype & cleanups
- From: Zack Weinberg <zack at codesourcery dot com>
- Date: Wed, 24 Oct 2001 09:30:26 -0700
- Cc: neil at daikokuya dot demon dot co dot uk, gcc-patches at gcc dot gnu dot org,toon at moene dot indiv dot nluug dot nl
- References: <200110241600.MAA16739@caip.rutgers.edu>
On Wed, Oct 24, 2001 at 12:00:34PM -0400, Kaveh R. Ghazi wrote:
> > From: Neil Booth <neil@daikokuya.demon.co.uk>
> > Kaveh R. Ghazi wrote:-
> > > One note, there was no direct equivalent to is_hor_space in
> > > safe-ctype, so it became ISSPACE && != '\n'.
> >
> > is_nvspace() is what cpplib uses.
> > Neil.
>
> Yes but as I alluded to in my original posting, its not an exact
> match, is_hor_space is true for ' ', '\t', '\v', '\f' and '\r' while
> is_nvspace is true for ' ', '\t', '\v', '\f', and '\0'.
>
> The difference is '\r' vs '\0'.
The reason \r isn't in is_nvspace is because it's vertical space: \r\n
is the DOS line terminator and \r alone is the pre-OSX Mac line
terminator. cpplib wants to be able to cope with whichever form you
throw at it. It would be a good thing if all GCC front ends did the
same.
'\0' is in is_nvspace because we decided it made the most sense to
treat it as whitespace. It's a bit risky to add that to the set used
by Fortran without making sure that this won't break anything else.
zw