mirror of
https://github.com/irungentoo/toxcore.git
synced 2024-03-22 13:30:51 +08:00
55a76003b0
memset() treats the passed buffer as a char* array, assigning to every 1-byte of the array the value. So for a single 4-byte int32_t element, it is assigning bytes 0, 1, 2 and 3 of it to -1. It happens that -1 is 0xFF, so in the end the uint32_t is set to 0xFFFFFFFF, which is -1 in the two's complement, so the memset() actually produces the correct result in the end, assuming the platform uses two's complement integers. Assigning it in the loop is less error-prone, as using memset() on non-1-byte wide arrays with a non-zero value is fishy, and it is more portable as we don't have to assume the use of two's complement. It looks like in a future version of the C standard, C23, two's complement is the only integer format in C23 (thanks to @robinlinden on IRC for pointing that out), so perhaps we shouldn't be as concerned with the portability here? Though @iphydf says that it's still a good idea to use a for-loop for this case. |
||
|---|---|---|
| .. | ||
| analysis | ||
| astyle | ||
| bootstrap_daemon | ||
| docker | ||
| emscripten | ||
| fun | ||
| pkgconfig | ||
| proxy | ||
| rpm | ||
| bootstrap_node_packets.c | ||
| bootstrap_node_packets.h | ||
| BUILD.bazel | ||
| DHT_bootstrap.c | ||
| DHTnodes | ||
| make_single_file | ||
| Makefile.inc | ||
| osx_build_script_toxcore.sh | ||
| print-version | ||
| tox-warning.png | ||
| tox.png | ||
| version-sync | ||
| windows_build_script_toxcore.sh | ||
