Open dcooley opened 1 year ago
I am fairly confident that this function will not overflow due to our unit and fuzzer tests that try to alert us if this function were to try to write beyond its buffer. It is of course dependent on certain details like single char
character encoding. That being said I don't think I could guarantee that there isn't some exotic scenario that I haven't considered.
My recollection from when I looked at this before was that snprintf
and related functions were not totally portable. I think some of the incompatibility dealt with edge cases and how failures are signaled, perhaps something that would still allow us to use them?
Another thing that occurred to me is that we might want to offer a compiler flag to simply omit these string functions. I think it's fairly common for bindings to simply replace them with versions directly in the bound language, due to the complexity of marshaling a string between C and managed runtimes. (java, python, and not applicable in JS)
Regarding your code suggestion, sadly I do not think that sizeof(str)
is correct. C does not know the actual size of the buffer pointed to by str
, so this will actually be the size of the pointer (thus why C has lots of problems with this kind of thing).
Question
The
h3ToString
function usessprintf()
. Is it possible / worth replacing withsnprintf()
?For example, as noted in https://rules.sonarsource.com/c/RSPEC-6069/,
(I'm not a full-on C-programmer, so it may be the case that the
sz < 17
, and theH3Index h
(uint64_t
) themselves guarantee this overflow won't occur?)Usecase / Background
I'm building an R library using
h3
, but upcoming versions of R* won't acceptsprintf
in compiled code due to the security risk.*
Not strictly R itself, but rather the official repositry of R packagse, CRAN