diff options
| author | Yifeng Li <tomli@tomli.me> | 2023-02-20 10:35:16 +0000 |
|---|---|---|
| committer | Sam James <sam@gentoo.org> | 2023-02-20 13:48:16 +0000 |
| commit | 3ab5b78c47ee2dcfdb2de0ae84f43c96d2e9c210 (patch) | |
| tree | c58905686bb1a776ee7ef2df02ec460bc9d1aa0d /dev-python/python-swiftclient | |
| parent | 22fec2d6f125a398305f113f2460bb15befb24eb (diff) | |
| download | gentoo-3ab5b78c47ee2dcfdb2de0ae84f43c96d2e9c210.tar.gz gentoo-3ab5b78c47ee2dcfdb2de0ae84f43c96d2e9c210.tar.bz2 gentoo-3ab5b78c47ee2dcfdb2de0ae84f43c96d2e9c210.zip | |
sys-devel/flex: fix crash on Apple M1 due to undefined behavior.
Currently, when the NULL-terminated variadic function
filter_create_ext() is invoked, the value "0" is passed as
the last argument to act as a terminator. However, this is
an integer value, which is incompatible with the pointer
data type expected by filter_create_ext().
This is undefined behavior in C, correct operation is not
guaranteed. In fact, it causes flex to crash on Apple M1
when GCC is used - the loop is not terminated when it should,
instead, it keeps running, corrupting the argument list for
invoking m4. As a result, it creates the following error:
> flex: fatal internal error, exec of gm4 failed
This commit fixes the problem by explicitly casting the value
0 to the correct pointer type (char *).
Since the existence of the bug doesn't always prevent a Gentoo
Prefix bootstrapping, it can lurk inside the system and remain
undetected, furthermore, it's technically a C programming bug,
other platforms could've been affected as well in theory. Thus,
we also bump the package version.
Closes: https://bugs.gentoo.org/871324
Signed-off-by: Yifeng Li <tomli@tomli.me>
Signed-off-by: Sam James <sam@gentoo.org>
Diffstat (limited to 'dev-python/python-swiftclient')
0 files changed, 0 insertions, 0 deletions
