* Add support for strings with \0 chars
* address feedback
* Increments minor version, adds comments, changes license year
Co-authored-by: Krzysztof Gabis <kgabis@gmail.com>
* Guard against potential integer overflow
If int res holds the value INT_MAX then adding 1 results in undefined
behavior. To guard against this possibility, cast res to size_t, not
the result of res + 1.
Fixes#132
* Increments version.
* More consitent parentheses when casting to size_t.
* Avoid truncating strings warning
GCC 8 introduced the `stringop-truncation` warning, which warns for
uses of `strncpy` of the form `strncpy(out, in, strlen(in))`. This
is often helpful, as this call would not copy the trailing `\0`,
potentially leading to subtle bugs.
With optimizations enabled, the function `parson_strndup` is
inlined, allowing the compiler to see that this call to `strncpy` is
of the form described above. GCC therefore outputs the warning.
In this case, the out buffer has already had the terminating `\0`
written to the end. Thus it is not necessary to copy it. GCC 9.2 is
not quite smart enough to recognize this, so it warns.
The warning is silenced by using `memcpy` instead of `strncpy`.
Although I have not benchmarked it, this change might reasonably
improve the performance of `parson_strndup`. `strncpy` checks every
byte for `\0` in addition to counting to `n`. `memcpy` does not need
to check whether the bytes it copies are `\0`.
However, if `parson_strndup` is frequently passed `char *`s with a
`\0` somewhere in the middle, then `memcpy` will copy more bytes
than necessary, hurting performance. In this case, a better solution
might be:
```
- output_string[n] = `\0`;
- strncpy(output_string, string, n);
+ strncpy(output_string, string, n+1);
```
* Increments parson's version.
SPDX-License-Identifier is useful to clarify the license (both for humans and
machines), especially when the code of the project is embedded into other
projects.
ref: https://spdx.org/using-spdx-license-identifier
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Some libraries don't have sscanf and since it wasn't used heavily it was easily replaced with a custom function. This doesn't mean that sscanf won't be used in future though (but I'll try to avoid it).
Fixes#68. Thanks to @compulim for initial work on this issue.
