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. The "CCREnableFwUpdateMode" and "CCRDisableFwUpdateMode" functions also appear to identical, apart from their debug output.<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)
+
:Yeah, I'm relearning C++, still haven't quite gotten down typecasting/interaction or pointers, it's more to give a rough idea of what it's doing in the library but I assume I should just ditch it and stick to just documenting prototypes. [[User:NWPlayer123|NWPlayer123]] ([[User talk:NWPlayer123|talk]]) 21:03, 21 April 2016 (CEST)