New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alterations to handling of \013 in source files breaking other tools #6165
Comments
Comment author: @dra27 Getting libraries primarily written with Unix in mind to support Windows is already enough of a faff - would it be acceptable for the OCaml lexer to be slightly more forgiving about stray \r characters while still retiring MacOS 9 support? |
Comment author: @protz I'll ask François Pottier on Monday if he can easily fix this on the Menhir side, which would save Damien the hassle of issuing a rc3. I still agree that we should be more forgiving about \r's, but if we could postpone this to the next bugfix release, that would save Damien some trouble I think. |
Comment author: @protz François and I fixed the problem on the Menhir side. Menhir now compiles just fine on Windows (and generates proper files without extra \r's). A new release will be issued shortly. |
Comment author: @dra27 OK - would the intention still be to consider/target this patch for ocaml-next (or whatever the new marker is!), though? |
Comment author: @protz I would be in favor of a warning that's "as-error" by default (you could then override it, but we would be pretty harsh already). Thoughts? :) |
Comment author: @dra27 A warning's a good idea - though perhaps as warning, rather than as error? To me, it's part of the "be liberal in input you receive and strict in output you send" mantra. What we're concerned about is that there's a newline which, for the two major OS categories supported means a \n. My other "objection" is that the current regular expression is very strict about an incorrect number of \rs (e.g. \r\r\n) but doesn't care about mixed Windows and Unix linebreaks in the same file (e.g. \r\n used for some lines and \n for the others). |
Comment author: @damiendoligez
This is a feature request that I view with a very favourable eye. |
Comment author: @protz
That's a good point, so I'm in favor of reverting to a more forgiving behavior as well. |
Comment author: @damiendoligez Patch applied in 4.01 branch (commit 14404) and trunk (commit 14405). |
Original bug ID: 6165
Reporter: @dra27
Status: closed (set by @damiendoligez on 2014-01-22T13:04:42Z)
Resolution: fixed
Priority: normal
Severity: major
Version: 4.01.0+beta/+rc
Target version: 4.01.1+dev
Fixed in version: 4.01.1+dev
Category: platform support (windows, cross-compilation, etc)
Tags: patch, junior_job
Related to: #5598
Bug description
#5598 alters parsing/lexer.mll so that "\r" is no longer allowed as a line breaking character (removing legacy MacOS 9 and earlier support). Unfortunately, this is also crashing external tools (in particular, menhir) which accidentally generate \r\r\n on Windows (this may happen when \r\n is erroneously passed through a print routine which expects \n on all platforms).
Steps to reproduce
Attempt to build menhir-20130116 on Windows using the mingw 32-bit port and OCaml 4.01.0+rc2
Additional information
See also https://sympa.inria.fr/sympa/arc/caml-list/2013-08/msg00009.html
File attachments
The text was updated successfully, but these errors were encountered: