Can you explain why it is not possible to fix? It seems that “backwards compatibility” should not mean maintaining reliance upon unintended bugs.
stevensonmt
HP4k1h5
i don’t know what the best way forward is in situations like these, but “backwards compatability” is often cited as a way of shorthanding reasons that others might understand. i’ve never really understood the constraints on this justification or how unbounded its parameters. changing anything or adding anything to a language could always break something somewhere on some machine.
is there really someone running critical code that depends on the “faulty”? implementation of a regex api? is this same person, all at the same time constantly, a) not maintaining the software itself, b) IS updating elixir on release, c) not testing the regex with the updated version?
it seems like all of software update management is based on this exact person and NO other persons or use cases. this someone who runs theoretically “important” code that they DON’T maintain but DO update the runtime for, so regularly and without any tests, such that no one can have a working regex in the real world? mind you this person also has to be running code that relies on a quirk in the implementation of a regex module. Seems almost guaranteed that a) such a person doesn’t really matter, and b) there’s lots of people who are probably using the regex incorrectly given their expectations and its actual behavior.
1
derek-zhou
Backwards compatibility is super-duper important, at least for all long term successful software projects. As @hauleth has explained, this bug involved 3 parties:
- erlang
- pcre
- libc
The latter two are outside erlang’s control, and changing erlang alone will break backward compatibility, not only in the way of [:accii:] but many things else also.
0
Sebb
OTP uses pcre 8.44 while the latest is 10.37-RC1.
The problem may not occur with the latest pcre.
0
stevensonmt
I did not mean to suggest backwards compatibility should be ignored. I was more wondering why fixing this bug would be a breaking change as depending upon unintended behavior is not something I expect to be generally supported. As for this being outside the control of erlang or Elixir, I lack the technical expertise to know so I defer to you on that. From reading the links in @hauleth’s posts it seems that as character classes are defined according to the locale, is it not possible to set the locale to some standard at compile time such that the class can then be depended to return the same matches regardless of the locale setting on the local system at runtime? If that is possible, would that represent a breaking change?
0
hauleth
It is how it works right now. Just the locale is set to sv_SE.Latin-1 instead of “expected one” C locale.
1
derek-zhou
I was not aware that OTP forked pcre. In this case maybe the OTP team can fix the bug in pcre and push a patch upstream.
0
stevensonmt
ianheggie
My locale Australia (apart from time is GB as I want weeks to start monday):
$ locale
LANG=en_AU.UTF-8
LANGUAGE=en_AU:en_AU:en
LC_CTYPE="en_AU.UTF-8"
LC_NUMERIC=en_AU.UTF-8
LC_TIME=en_GB.UTF-8
LC_COLLATE="en_AU.UTF-8"
LC_MONETARY=en_AU.UTF-8
LC_MESSAGES="en_AU.UTF-8"
LC_PAPER=en_AU.UTF-8
LC_NAME=en_AU.UTF-8
LC_ADDRESS=en_AU.UTF-8
LC_TELEPHONE=en_AU.UTF-8
LC_MEASUREMENT=en_AU.UTF-8
LC_IDENTIFICATION=en_AU.UTF-8
LC_ALL=
0