Bug 14878 - gap.awk makes bad conversion tables if u+0001.. u+0006 not mapped
Summary: gap.awk makes bad conversion tables if u+0001.. u+0006 not mapped
Status: NEW
Alias: None
Product: glibc
Classification: Unclassified
Component: localedata (show other bugs)
Version: 2.17
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-26 13:56 UTC by John Hughes
Modified: 2014-06-14 11:02 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-

Attachments
charmap that shows the bug (302 bytes, application/octet-stream)
2012-11-26 13:56 UTC, John Hughes 		Details
patch to gap.awk and gaptab.awk to fix bug (378 bytes, patch)
2012-11-26 13:57 UTC, John Hughes 		Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description John Hughes 2012-11-26 13:56:55 UTC 
Created attachment 6753 [details]
charmap that shows the bug

If a charmap doesn't define a mapping for at least one character in the range u+0001 to u+0006 then the translation table generated by gap.awk is broken.  For example with the attached TEST charmap then u+0041 gets mapped to a \4a instead of \x41.

The bug happens because gap.awk sets "last" (the last codepoint output) to zero, instead of -1.  A patch to gap.awk and gaptab.awk is attached.
Comment 1 John Hughes 2012-11-26 13:57:48 UTC 
Created attachment 6754 [details]
patch to gap.awk and gaptab.awk to fix bug