<div dir="ltr">Hi,<div>I am trying to write a rule to extract more info from BigTIFF.  Currently, TIFF files extract directory entries and output metadata, while BigTIFF only reports the file type and endian.<br><br>Working from this page, <a href="http://bigtiff.org/" target="_blank">http://bigtiff.org/</a> I am trying to read the offset to the first directory entry; in TIFF, this is a short (16-bit), while in BigTIFF, it's a quad (64-bit) to support files with very large offsets.</div><div><br></div><div>As such, I am trying to write this continuation:</div><div>>>>(8.Q) use              \^bigtiff_ifd<br></div><div>Which IIUC is saying "starting at file offset 8, read a bequad (64 bit) and then recursively call the named magic bigtiff_ifd (which is slightly different from tiff_ifd).</div><div><br></div><div>When I try this on my test file (a big-endian BigTIFF), I get this debug error:</div><div></div><div>10: >>>> 8(bequad,&0), use,='^bigtiff_ifd',""]<br>lhs/off overflow 28956860354 0<br></div><div><br></div><div>If I understand the code in do_ops correctly (<a href="https://github.com/file/file/blob/master/src/softmagic.c#L1465" target="_blank">https://github.com/file/file/blob/master/src/softmagic.c#L1465</a>) </div><div>the values for lhs and off are compared to UINT_MAX and INT_MIN, and a failure is reported if the value is too large.</div><div>On my 64-bit system, UINT_MAX seems to be based on 32-bit integer, which causes the overflow error when compared against a 64-bit value.</div><div><br></div><div>Before I proceed, wanted a sanity check here: are 64-bit offsets larger than 2**32 considered invalid by file?</div><div><br></div></div>