Cabal config corrupted when using Unicode #2557
Assignees
Comments
|
Looks like we just need to let GHC handle the text encoding for us, rather than going through ByteString. |
|
Once this is fixed, we should also add a regression test. |
|
@ttuegel you self-assigned this bug 2 years ago... did you make any progress? Do you mind if I try giving this one a shot myself? ;-) |
|
@hvr Have at it! I think at the time I had some reason to believe this would be simple to fix, but I never got to it. |
hvr
added a commit
to hvr/cabal
that referenced
this issue
Dec 17, 2018
The config-state header is a human readable line prepended to the
binary serialisation which looks like
Saved package config for pkgname-1.2.3 written by Cabal-2.5.0.0 using ghc-8.6
However, the functions generating and parsing this header didn't take into
account that package names are not limited to the ASCII subset and blindly used
the ByteString `pack` function which truncates away the high bits of the `Char`
code point resulting in a corrupted header with a non-sensical package-name.
The fix is simply to serialise the package-name with the UTF-8 encoding which
works nicely with the rest of the UTF-8 unaware string handling functions.
Hence the fix is a lot shorter than this commit message.
Fixes haskell#2557
hvr
added a commit
to hvr/cabal
that referenced
this issue
Dec 17, 2018
…encoding This takes care of knock-off effects of haskell#2557 Specifically, the `Paths_*.hs` and `cabal_macros.h` files would result being incorrectly by a `rewriteFileEx` which isn't UTF-8 capable. Now the `cabal_macros.h` file is written out exactly like the `.h` file generated internally by `ghc` is generated; note however that standard CPP doesn't support non-ASCII characters in CPP symbols and will thus not work with a standard CPP preprocessor.
hvr
added a commit
to hvr/cabal
that referenced
this issue
Jan 16, 2019
The config-state header is a human readable line prepended to the
binary serialisation which looks like
Saved package config for pkgname-1.2.3 written by Cabal-2.5.0.0 using ghc-8.6
However, the functions generating and parsing this header didn't take into
account that package names are not limited to the ASCII subset and blindly used
the ByteString `pack` function which truncates away the high bits of the `Char`
code point resulting in a corrupted header with a non-sensical package-name.
The fix is simply to serialise the package-name with the UTF-8 encoding which
works nicely with the rest of the UTF-8 unaware string handling functions.
Hence the fix is a lot shorter than this commit message.
Fixes haskell#2557
hvr
added a commit
to hvr/cabal
that referenced
this issue
Jan 16, 2019
…encoding This takes care of knock-off effects of haskell#2557 Specifically, the `Paths_*.hs` and `cabal_macros.h` files would result being incorrectly by a `rewriteFileEx` which isn't UTF-8 capable. Now the `cabal_macros.h` file is written out exactly like the `.h` file generated internally by `ghc` is generated; note however that standard CPP doesn't support non-ASCII characters in CPP symbols and will thus not work with a standard CPP preprocessor.
hvr
added a commit
to hvr/cabal
that referenced
this issue
Mar 3, 2019
The config-state header is a human readable line prepended to the
binary serialisation which looks like
Saved package config for pkgname-1.2.3 written by Cabal-2.5.0.0 using ghc-8.6
However, the functions generating and parsing this header didn't take into
account that package names are not limited to the ASCII subset and blindly used
the ByteString `pack` function which truncates away the high bits of the `Char`
code point resulting in a corrupted header with a non-sensical package-name.
The fix is simply to serialise the package-name with the UTF-8 encoding which
works nicely with the rest of the UTF-8 unaware string handling functions.
Hence the fix is a lot shorter than this commit message.
Fixes haskell#2557
hvr
added a commit
to hvr/cabal
that referenced
this issue
Mar 3, 2019
…encoding This takes care of knock-off effects of haskell#2557 Specifically, the `Paths_*.hs` and `cabal_macros.h` files would result being incorrectly by a `rewriteFileEx` which isn't UTF-8 capable. Now the `cabal_macros.h` file is written out exactly like the `.h` file generated internally by `ghc` is generated; note however that standard CPP doesn't support non-ASCII characters in CPP symbols and will thus not work with a standard CPP preprocessor.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The text was updated successfully, but these errors were encountered: