View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000562 | file | General | public | 2024-09-15 13:42 | 2024-09-15 13:42 |
| Reporter | jsummers | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Product Version | 5.45 | ||||
| Summary | 0000562: Using "search" in a "name" item messes up the current offset | ||||
| Description | Write a magic pattern that calls a "name" item using "use", with a nonzero offset. Like: >64 use some_named_item Inside the corresponding "name" item, do a "search" or "regex". Then if the search succeeded, try to read the next field after the match, using a relative offset. E.g.: 0 name some_named_item >0 search ABC >>&0 ubyte x %u It doesn't work. It reads the file at a completely wrong offset (I guess it's wrong by an amount equaling the offset in the "use" line). | ||||
| Steps To Reproduce | Using the attached files... $ file -m searchbug.magic searchbug.dat searchbug.dat: Testfmt (0) found_ABC followed_by 0x31 at_offset 11 (64) found_ABC followed_by 0x2a at_offset 139 Expected: searchbug.dat: Testfmt (0) found_ABC followed_by 0x31 at_offset 11 (64) found_ABC followed_by 0x32 at_offset 75 | ||||
| Additional Information | Here are the only files I could find in the included pattern database that *might* trigger the bug. I haven't tried to verify any of them. c64 (lines 358->658->660) nim-lang (lines 9->18->19) ole2compounddocs (lines 64->317->321) rtf (lines 78->39->41) | ||||
| Tags | No tags attached. | ||||
