Andrew Williams

Oh ok, that makes sense... Is the correct way to know whether an instruction requires the 0x66 prefix to actually look for `OSZ=1`, then (in addition to looking for instructions...

Oh, I thought if an instruction had `EOSZ=1` in the pattern it was an instruction for which 0x66 could be added to leverage 16b operands in 32b mode. That assumption...

@strictlymike Any thoughts on this issue/pull request? This is still an issue last I checked. Thanks!

Should there be a new button in the UI for this, or should it just be part of the 'Rename functions' functionality? FYI, here is an ARM sample: https://detux.org/report.php?sha256=8d9dd4f611e7d66769f44877b95f4b387c093bc58d701b1695e2b75fc5ce178b

Here's the binary I was analyzing (if you create an account you should be able to download the sample): https://detux.org/report.php?sha256=9d6809571bec7429098bcb7ca0b12f8cb094d9079c6765b10a9c90b881ee9d37 BTW, your scripts were a big help in analyzing this...

I believe I've address all feedback with the most recent commit, but please let me know if I missed anything.

To call out some of the current differences between the ABNF section and the parsing algorithm (not an exhaustive list - just the ones I've happened to notice): ``` cookie-pair...

I've observed multiple instances where the grammar from 4.4.1 is copied into discussions/code related to cookie parsing and used as if it was the syntax that all cookies MUST adhere...

Hmm, another difference is that in the `Storage Model` section, the control character checks only apply to `cookie-name` and `cookie-value`, but since the corresponding checks in the `Set-Cookie Header Field`...

One thing that complicates the `Storage Model` section, especially when considering cookies set via non-HTTP APIs like Cookie Store API, is that attribute values aren't direct inputs to the `Storage...