summaryrefslogtreecommitdiff
path: root/doc/forum
diff options
context:
space:
mode:
authorGravatar Joey Hess <joeyh@joeyh.name>2017-06-17 16:17:09 -0400
committerGravatar Joey Hess <joeyh@joeyh.name>2017-06-17 16:48:00 -0400
commit3adf1ea63d9b5feccd4e6cb457fbbb52fdfc9fe0 (patch)
treebb68382446f50f6687dde96de1816d881bac655a /doc/forum
parent9f375315d220169240e0e99a667601136b3e06e9 (diff)
fix failing quickcheck properties
QuickCheck 2.10 found a counterexample eg "\929184" broke the property. As far as I can tell, Git.Filename is matching how git handles encoding of strange high unicode characters in filenames for display. Git does not display high unicode characters, and instead displays the C-style escaped form of each byte. This is ambiguous, but since git is not unicode aware, it doesn't need to roundtrip parse it. So, making Git.FileName's roundtrip test only chars < 256 seems fine. Utility.Format.format uses encode_c, in order to mimic git, so that's ok. Utility.Format.gen uses decode_c, but only so that stuff like "\n" in the format string is handled. If the format string contains C-style octal escapes, they will be converted to ascii characters, and not combined into unicode characters, but that should not be a problem. If the user wants unicode characters, they can include them in the format string, without escaping them. Finally, decode_c is used by Utility.Gpg.secretKeys, because gpg --with-colons hex-escapes some characters in particular ':' and '\\'. gpg passes unicode through, so this use of decode_c is not a problem. This commit was sponsored by Henrik Riomar on Patreon.
Diffstat (limited to 'doc/forum')
0 files changed, 0 insertions, 0 deletions