View Single Post
Posts: 1,808 | Thanked: 4,272 times | Joined on Feb 2011 @ Germany
#52
Now that said what WOULD be a good reason to take the approach of not writing in the c-string terminating null, is if you set R&D mode settings on using Nokia's Flasher, then try to read it with R&D mode control and that gives problems (this being completely not caused by the +1 but by the fact that the strings coming out would have no terminating null for my code then (or the standard c-string functions thereof) to stop at), then I will, for the sake of compatibility and consistency, write the strings without the terminating null to the cal block and compensate for the lack thereof in my own code when pulling the string out.
Exactly. Your using of the +1 is a kind of workaround for using string functions when libcal actually uses "Pascal-type" strings, i.e. a block and a length, and memcpy instead of strcpy, etc.

If you do rewrite your rd program you might want to go that route, which would sort of fit better with libcal. But this is (likely) a very academic issue. At least R&D mode is essentially treated like a (C-)string.

But if you consider expanding your program to other regions/blocks of cal (think "bme", "phone-info", "wlan-tx-cost3_0", "fmtx_pwl", "lock_code", "lock_period", "lock_enable", etc.) then you'll have to make sure that you read/write exactly as expected by the library (and any other client programs making use of the library..)

Cheers, and congratulations for making it possible to manipulate R&D mode from the recovery console. This is actually seriously cool!
 

The Following 3 Users Say Thank You to reinob For This Useful Post: