summaryrefslogtreecommitdiffstats
path: root/.github/workflows/README.md
diff options
context:
space:
mode:
authorYann Collet <cyan@fb.com>2022-09-12 21:28:24 (GMT)
committerYann Collet <cyan@fb.com>2022-09-12 21:28:24 (GMT)
commitd91d16b48aa22f179f636123869ea4fbe1d8ccdb (patch)
tree7b31c42ff590424a071ef17afbfb124e4d45b494 /.github/workflows/README.md
parent9bed6b56e9beb1cf820f01e47e70a13442d33544 (diff)
downloadlz4-d91d16b48aa22f179f636123869ea4fbe1d8ccdb.zip
lz4-d91d16b48aa22f179f636123869ea4fbe1d8ccdb.tar.gz
lz4-d91d16b48aa22f179f636123869ea4fbe1d8ccdb.tar.bz2
updated documentation : no more issue with 32-bit compilation on recent compilers
Diffstat (limited to '.github/workflows/README.md')
-rw-r--r--.github/workflows/README.md29
1 files changed, 8 insertions, 21 deletions
diff --git a/.github/workflows/README.md b/.github/workflows/README.md
index 9ad2d99..2c9071a 100644
--- a/.github/workflows/README.md
+++ b/.github/workflows/README.md
@@ -6,31 +6,18 @@ This directory contains [GitHub Actions](https://github.com/features/actions) wo
For now, `lz4-ubsan-*` uses the `-fsanitize-recover=pointer-overflow` flag:
there are known cases of pointer overflow arithmetic within `lz4.c` fast compression.
-These cases are not dangerous with current architecture,
+These cases are not dangerous with known architecture,
but they are not guaranteed to work by the C standard,
which means that, in some future, some new architecture or some new compiler
-may decide to do something funny that would break this behavior.
-Hence it's proper to remove them.
-This has been done in `lz4hc.c`.
-However, the same attempt in `lz4.c` resulted in massive speed loss,
-which is not acceptable to solve a "potential future" problem that does not exist anywhere today.
-Therefore, a better work-around will have to be found.
+may decide to do something funny that could break this behavior.
+Hence, in anticipation, it's better to remove them.
+This has been already achieved in `lz4hc.c`.
+However, the same attempt in `lz4.c` resulted in massive speed losses,
+which is not an acceptable cost for preemptively solving a "potential future" problem
+not active anywhere today.
+Therefore, a more acceptable work-around will have to be found first.
-## C Compilers (`lz4-c-compilers`)
-
-- Our test doesn't use `gcc-4.5` due to installation issue of its package. (`apt-get install gcc-4.5` fails on GH-Actions VM)
-
-- Currently, the following 32bit executable tests fail with all versions of `clang`.
- - `CC=clang-X CFLAGS='-O3' make V=1 -C tests clean test-lz4c32`
- - `CC=clang-X CFLAGS='-O3 -mx32' make V=1 -C tests clean test-lz4c32`
- - See [#991](https://github.com/lz4/lz4/issues/991) for details.
-
-- Currently, the following 32bit executable tests fail with `gcc-11`
- - `CC=gcc-11 CFLAGS='-O3' make V=1 -C tests clean test-lz4c32`
- - `CC=gcc-11 CFLAGS='-O3 -mx32' make V=1 -C tests clean test-lz4c32`
- - See [#991](https://github.com/lz4/lz4/issues/991) for details.
-
## cppcheck (`lz4-cppcheck`)