libstdc++'s |memcpy| and |memset| both state that their inputs should
never be a nullptr since this matches the C spec. Some compilers act on
these hints, so we shouldn't unconditionally call these as it would
signal to the compiler that they can't be nullptrs.
As an example, the following code will always call |do_something()|
when compiled with optimisations since GCC version 4.9:
```
void clear(void *ptr, int size) {
memset(ptr, 0, size);
}
void example(void *ptr, int size) {
clear(ptr, size);
if (ptr != nullptr) do_something();
}
```
The result of a left shift on a positive signed integer (Rune) must fit
into an unsigned integer otherwise it's undefined behaviour, as is left
shifting a negative integer by any amount. This code can only be hit if
|x >= 0xf0| and hence a left shift of 31 will always be undefined
unless the input is 0 or 1.
To avoid hitting this we can instead extend the lowest bit to be the
mask if we assume that ints are 2's complement, which we already do
elsewhere. This generates identical code in testing on Compiler
Explorer and the Odin test suite passes locally with this change.
Note that the original code would change to be defined behaviour in
C++20, however we are currently build with |-std=c++14| in the build
scripts.
If |result_count| is 0 then |results| will be a nullptr and hence the
access |results->Tuple| is undefined behaviour. There's already an
early return in the 0 branch so move that to be the first thing so that
we can guarantee that it's not a nullptr.
Note that technically we take the address of the result so it's not
actually dereferencing it, however UBSan doesn't care about that.
UBSan spotted that |src->Basic.kind| had a value outside the range of
|BasicKind| due to it actually being a |Type_Pointer|. Since these are
stored in a union there could be cases where the value of |kind| just
so happens to be |Basic_string|, in which case the branch would have
been taken when it shouldn't have been.
To fix this simply check that it's a |Type_Basic| before treating it as
a |Basic|.
For utterly unrealistic constant sizes, this still crashes on my system,
but it crashes fast due to the OOM killer, and people using rediculously
large exponents get what they deserve.
Laytan Laatsandflysand7
gingerBillandflysand7
Jeroen van Rijnandflysand7
jakubtomsuandflysand7
bayo-codeandflysand7
Morten Hauke Solvangandflysand7
Dominik Pötzschkeandflysand7
0dminnimdaandflysand7
peachey2k2andflysand7
bobsayshilolandflysand7
Yawning Angelandflysand7
Misomosiandflysand7