* cp437 issue with bad mapping at least for one char
@ 2017-11-22 2:50 Jacob Thrane Lund
2017-11-22 3:25 ` Rich Felker
0 siblings, 1 reply; 2+ messages in thread
From: Jacob Thrane Lund @ 2017-11-22 2:50 UTC (permalink / raw)
To: musl
[-- Attachment #1: Type: text/plain, Size: 691 bytes --]
Hi musl devs,
I experienced a test failing when building the latest version of gammu for Alpine Linux.
After reporting the issue to the gammu developer the reached conclusion was the issue is with musl -
https://github.com/gammu/gammu/issues/303#issuecomment-345258460
I have checked the log for https://git.musl-libc.org/cgit/musl/commit/src/locale/codepages.h and Rich Felker pushed a commit 8 days ago. As of yet I have not had the chance to verify if this also resolves this issue. Dealing with charsets at this level is for me totally new territory.
I was hoping you could confirm/deny if Rich’s commit indeed also resolves my issue?
Yours sincerely
Jacob aka TBK
[-- Attachment #2: Type: text/html, Size: 750 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: cp437 issue with bad mapping at least for one char
2017-11-22 2:50 cp437 issue with bad mapping at least for one char Jacob Thrane Lund
@ 2017-11-22 3:25 ` Rich Felker
0 siblings, 0 replies; 2+ messages in thread
From: Rich Felker @ 2017-11-22 3:25 UTC (permalink / raw)
To: musl
On Wed, Nov 22, 2017 at 03:50:48AM +0100, Jacob Thrane Lund wrote:
>
> Hi musl devs,
>
> I experienced a test failing when building the latest version of gammu for Alpine Linux.
>
> After reporting the issue to the gammu developer the reached conclusion was the issue is with musl -
> https://github.com/gammu/gammu/issues/303#issuecomment-345258460
>
> I have checked the log for
> https://git.musl-libc.org/cgit/musl/commit/src/locale/codepages.h
> and Rich Felker pushed a commit 8 days ago. As of yet I have not had
> the chance to verify if this also resolves this issue. Dealing with
> charsets at this level is for me totally new territory..
>
> I was hoping you could confirm/deny if Rich’s commit indeed also resolves my issue?
It does. Here is how CP437 decodes, before:
Çüéâäàåç êëèïîìÄÅ ÉæÆôöòûù ÿÖÜ¢£¥₧ƒ ¡¢£¤¥¦§ ¨©ª«¬®¯ ░▒▓│┤╡╢╖ ╕╣║╗╝╜╛┐
└┴┬├─┼╞╟ ╚╔╩╦╠═╬╧ ╨╤╥╙╘╒╓╫ ╪┘┌█▄▌▐▀ αáΓπΣσæτ ΦΘΩδìφεï ðñ≥≤⌠⌡÷≈ °∙·√ü²■
and after:
Çüéâäàåç êëèïîìÄÅ ÉæÆôöòûù ÿÖÜ¢£¥₧ƒ áíóúñѪº ¿⌐¬½¼¡«» ░▒▓│┤╡╢╖ ╕╣║╗╝╜╛┐
└┴┬├─┼╞╟ ╚╔╩╦╠═╬╧ ╨╤╥╙╘╒╓╫ ╪┘┌█▄▌▐▀ αßΓπΣσµτ ΦΘΩδ∞φε∩ ≡±≥≤⌠⌡÷≈ °∙·√ⁿ²■
The problem (silently fixed) was that the table generation code for
legacychars.h ignored entries in the Unicode charmap files that used
lowercase a-f in the hex, _and_ omitted characters that appeared in
the same slot as their Unicode codepoint (in all the ISO-8859
encodings containing í, it appears in "its own" slot), since these
previously got a special encoding. If not for the latter, this
character would have been included in the legacychars.h map already
due to being in Latin-1, where the charmap file used uppercase.
Somehow when the character was missing in legacychars.h, the mapping
tables ended up containing nonsense.
Rich
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2017-11-22 3:25 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-22 2:50 cp437 issue with bad mapping at least for one char Jacob Thrane Lund
2017-11-22 3:25 ` Rich Felker
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).