View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000561 | file | General | public | 2024-09-13 14:23 | 2024-09-13 14:23 |
Reporter | jsummers | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | always |
Status | new | Resolution | open | ||
Product Version | 5.45 | ||||
Summary | 0000561: Weirdness with string16 fields near end of file | ||||
Description | There's a problem with reading lestring16/bestring16 fields that start near the end of the input file (where "near" usually means less than 254 bytes). It seems like the number of bytes available is being miscalculated, causing irrelevant bytes from elsewhere in the file to be appended to the string. | ||||
Steps To Reproduce | This bug can be hard to investigate if the input file contains 0-valued bytes, and such bytes are required by nearly all the relevant patterns included with the software. So, I'll demonstrate it by making a custom pattern file. $ echo -en '0 string TEST Testfmt\n>8 lestring16 x (%s)\n' > s16.magic $ echo -en 'TEST1234a_b_c_d_e_f_' > s16.dat $ file -m s16.magic s16.dat s16.dat: Testfmt (abcdef34a_b_c_d_e_f_) Expected result: s16.dat: Testfmt (abcdef) | ||||
Additional Information | I'm assuming the string16 features are kind of a hack, not expected to actually support Unicode. That's not the issue here, but you have to know that in order to make sense of this bug report. This isn't just a printing issue. The nonsense characters can also be matched in tests. | ||||
Tags | No tags attached. | ||||
Date Modified | Username | Field | Change |
---|---|---|---|
2024-09-13 14:23 | jsummers | New Issue |