[erlang-questions] Fwd: FW: Breaking backwards compatibility in Release 17.0-rc2

Richard Carlsson carlsson.richard@REDACTED
Fri Mar 7 08:01:13 CET 2014

On 2014-03-06 02:15 , Andreas Schumacher wrote:
> In OTP 17.0-rc{1,2}, a file that is encoded in latin-1 and contains
> non-UTF-8/non-ASCII-7 characters, causes a compiler error similar to the
> following:
>    tst.erl:1: cannot parse file, giving up
>    tst.erl:1: no module definition
>    tst.erl:1: cannot translate from UTF-8
> In OTP 17.0, if a file is encoded in latin-1 and contains
> non-UTF-8/non-ASCII characters, but does not declare the encoding with a
> magic encoding comment at the beginning of the file, epp (the Erlang
> code pre-processor) issues a deprecation warning, and processes the file
> again, assuming latin-1 encoding.
> In a future major version, preferably in OTP 18, the deprecation warning
> will be turned into an error again. That is, only UTF-8 encoded files,
> and files that declare the source code encoding at the beginning of the
> source code file, will be accepted.

Still not good enough. I want to be able to move up to R18 when that 
time comes without having to modify files all over our codebase. (And 
retrying is an ugly workaround anyway.) The following patch has allowed 
me to compile all of our sources under R17 by simply adding 
'+{default_encoding,latin1}' to the erlc options in our Makefiles:



More information about the erlang-questions mailing list