Re: bug in scan-skel.l

[Hans Aberg]

At 00:16 -0800 2005/04/03, Paul Eggert wrote:
> "martin nylin" <address@hidden> writes:
>
> >  Where the programmer did not consider the fact that windoze uses two
> >  characters to represent end of line.
>
> The programmer shouldn't have to worry about that issue; the Microsoft
> Windows port should automatically convert \r\n to \n before Bison sees
> the characters.  Bison opens its files in text mode, to help make sure
> this happens.  If that's not working for you, please investigate why
> not.

I suggested that the newlines weren't converted when unpacking the 
Bison tar-file. If then the compiler knows how to read the nonlocal 
UNIX \n newlines, one gets a proper compile. But if the C function 
that converts \r\n does not recognize \n, one will get errors when 
running the program. It is undefined in the C standard what should 
happen such a case with the \n. For example, my Mac compiler used to 
swap \r and \n, as \r was the local Mac newline. But then \n will 
cause errors on a text file not converted to the local Mac convention.

What one can do is to convert also the text files to the local 
convention. An alternative, "more advanced", method that I used on 
Mac's, is to locate the C the source code of the C library function 
that Bison uses for text inputs that converts local newlines to \n, 
and add a copy of that one to the project. Then tweak those sources 
so that \n passes through as \n. The compiler I used then, when 
confronted with two copies of the C library function, will link the 
one external to the library.
--
  Hans Aberg