fix unicode indexing in parse(Complex, string) #51758
Conversation
stevengj
added
bugfix
stevengj
force-pushed
the
sgj/fixparsecomplex
branch
from
ebdd8ae to
8239fd6
Compare
| i₊ = something(findnext(in(('+','-')), s, i₊+1), 0) | ||
| end | ||
| if i₊ != 0 && s[i₊-1] in ('e','E') # exponent sign | ||
| if i₊ != 0 && s[prevind(s, i₊)] in ('e','E') # exponent sign |
There was a problem hiding this comment.
Note to self: Checks like this could be sped up further if we used codeunits(s) and did byte indexing/comparisons rather than Char comparisons. It would uglify the code and maybe the speedup would be small, however?
There was a problem hiding this comment.
(In any case, speedups to this function should go into a separate PR, not a bugfix PR, since speedups need not be backported.)
|
Unrelated CI failures, it looks like: |
This fixes a string-indexing bug introduced in #24713 (Julia 0.7). Sometimes, this would cause `parse(Complex{T}, string)` to throw a `StringIndexError` rather than an `ArgumentError`, e.g. for `parse(ComplexF64, "3 β+ 4im")` or `parse(ComplexF64, "3 + 4αm")`. (As far as I can tell, it can never cause parsing to fail for valid strings.) The source of the error is that if `i` is the index of an ASCII character in a string `s`, then `s[i+1]` is valid (even if the next character is non-ASCII) but `s[i-1]` is invalid if the previous character is non-ASCII. (cherry picked from commit f71228d)
KristofferC
removed
the
backport 1.10
This fixes a string-indexing bug introduced in #24713 (Julia 0.7). Sometimes, this would cause
parse(Complex{T}, string)to throw aStringIndexErrorrather than anArgumentError, e.g. forparse(ComplexF64, "3 β+ 4im")orparse(ComplexF64, "3 + 4αm"). (As far as I can tell, it can never cause parsing to fail for valid strings.)The source of the error is that if
iis the index of an ASCII character in a strings, thens[i+1]is valid (even if the next character is non-ASCII) buts[i-1]is invalid if the previous character is non-ASCII.