Fixed parsing hex numbers in chip config files

[gszy]

process_chipfile() used to improperly parse hex numbers in chip config files (*.chip), because it used atoi(), which read all such numbers as 0. This resulted, among other issues, in chip_id being set to 0 for all read chips. Such chip id could not match any actual MCU.

Replace the atoi() calls with sscanf(…, "%i", …), where %i should match integers in base 10, 8 and 16, depending on the number prefix.

---

I can rebase this PR once (if) #1166 is merged.

[Nightwalker-87]

@gszy: Please check for build failures, e.g.:

/home/runner/work/stlink/stlink/src/stlink-lib/chipid.c:1001:27: error: format ‘%i’ expects argument of type ‘int *’, but argument 3 has type ‘enum stlink_flash_type *’ [-Werror=format=]

You may also collect several issues in one PR for your convenience in the future - it shall be fine as well.

[gszy]

Sorry for the failures—now it should build cleanly, though I’m not sure if that’s a solution you approve:

// may set invalid flash types (not defined in enum stlink_flash_type)
if (sscanf(value, "%i", (int *) &ts->flash_type) < 1)

[Ant-ON]

@gszy This is a good solution to the problem!
Also you can add a check that this type of flash is supported (included in the range). To do this, you can add something like STLINK_FLASH_TYPE_MAX and check that the type is between 0 and maximum. This will help avoid problems with misconfigurations in the future.

[gszy]

You may also collect several issues in one PR for your convenience in the future - it shall be fine as well.

I’m trying to make my PRs small and easy to review 🙂

Also you can add a check that this type of flash is supported (included in the range). To do this, you can add something like STLINK_FLASH_TYPE_MAX and check that the type is between 0 and maximum.

I have added this check in separate commits (feel free to cherry pick what you find useful). There should be some range checks for other parameters as well, but I hope for another PR when I (or someone else) will find more time.

[Ant-ON]

@gszy Thank you!
Typos in other parameters should not result to segmentation failures. This is a critical parameter. Good job!