https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684
--- Comment #13 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> --- (In reply to Andy May from comment #12) > I don't know that it's necessary or desired to support both '\n' and '\r' as > eol, but instead the native eol just needs to be used consistently > everywhere, for example something like the following pseudo code: > > #ifdef __MINGW32__ > #define EOL '\r' > #else > #define EOL '\n' > #endif > ... > dtp->u.p.at_eol = (c == EOL || c == EOF); > Each compiler may choose to do this a little differently. In our case we see /r and look for the /n to eat it. If one is interested in reading a /r as data one should use access="stream" which allows you to do what ever you want. I could do something like the above, but it would touch quite a few places in the code which opens it up for mistakes and regressions (admittedly probably not any more than we get now and we could improve maintainability). Our personal time is a factor too. I have bigger bugs to fry and I don't get paid to do this. I do it in my spare time for the greater good of all. Regardless I do appreciate all input in this process of "open" software. (I should further audit the code when I get a chance)
