Difference between revisions of "Talk:Nsysccr.rpl"
Jump to navigation
Jump to search
(Created page with "This "reverse-engineered" code looks a little too much like a direct translation of assembly code to be considered "clean". There are mistakes (handle is consistently declared...") |
m |
||
| Line 1: | Line 1: | ||
| − | This "reverse-engineered" code looks a little too much like a direct translation of assembly code to be considered "clean". There are mistakes (handle is consistently declared as an int, not a pointer) and things that don't make sense such as why 0x3A4 bytes are allocated for a 4 byte value + ioctlv buffer for one parameter, and why the ioctlv buffer is at an offset of 0x80.<br> | + | This "reverse-engineered" code looks a little too much like a direct translation of assembly code to be considered "clean". There are mistakes (handle is consistently declared as an int, not a pointer) and things that don't make sense such as why 0x3A4 bytes are allocated for a 4 byte value + ioctlv buffer for one parameter, and why the ioctlv buffer is at an offset of 0x80. The "CCREnableFwUpdateMode" and "CCRDisableFwUpdateMode" functions also appear to identical, apart from their debug output.<br> |
The CRC code also appears incorrect as it's ignoring two out of every four bytes in the input data (running crc is uint16_t, data is uint32_t*). [[User:Tueidj|Tueidj]] ([[User talk:Tueidj|talk]]) 23:51, 18 April 2016 (CEST) | The CRC code also appears incorrect as it's ignoring two out of every four bytes in the input data (running crc is uint16_t, data is uint32_t*). [[User:Tueidj|Tueidj]] ([[User talk:Tueidj|talk]]) 23:51, 18 April 2016 (CEST) | ||
Revision as of 23:55, 18 April 2016
This "reverse-engineered" code looks a little too much like a direct translation of assembly code to be considered "clean". There are mistakes (handle is consistently declared as an int, not a pointer) and things that don't make sense such as why 0x3A4 bytes are allocated for a 4 byte value + ioctlv buffer for one parameter, and why the ioctlv buffer is at an offset of 0x80. The "CCREnableFwUpdateMode" and "CCRDisableFwUpdateMode" functions also appear to identical, apart from their debug output.
The CRC code also appears incorrect as it's ignoring two out of every four bytes in the input data (running crc is uint16_t, data is uint32_t*). Tueidj (talk) 23:51, 18 April 2016 (CEST)