Upstream codeql fixes#12
Open
deeprnd wants to merge 30 commits into
Open
Conversation
Test is broken and unused
Remove unused test-only coroutine library
- deps.sh: update Alpine package deps - Fix PAGE_SIZE identifier usage (conflicts with libc) - Fix sendmmsg flags integer type (different on musl vs glibc) - Fix usage of off64_t (better to use long) - Fix <sys/poll.h> include (better to use <poll.h>) - Fix sockaddr type punning with connect(2) - Fix usage of dirent64 (better to use dirent, which is identical) - Don't assume struct rlimit->resource is uint - Enable bpf syscall wrappers for musl libc - Fix missing <linux/ip.h> include when using <linux/if_tunnel.h>
Fossil code, broken since several years
Remove all alloca usages except in monitor.c and watch.c.
FD_HAS_INT128 implies 'has fast hardware support for int128'. But all supported compilers still provide software emulation for floating point numbers, wide/128-bit multiplies, etc. Therefore, provide basic uint128 type support.
This fixes build flakiness with noarch64 targets and FD_HAS_INT128 guard spam. Full Firedancer *requires* uint128 compiler support, but tolerates the absence of fast hardware wide multiplies on exotic targets. Therefore, remove unnecessary FD_HAS_INT128 compile guards and just assume that compilers can soft-emulate uint128 type support. (True for all supported compilers) Also clean up unnecessary uint128 usages along the way, mostly used as a futile attempt to get 16-byte atomic load/store. This doesn't actually work in practice. src/util and other libraries written by Kevin are more portable to exotic targets. But full Solana runtime support without compiler uint128 support has proven impossible to do in C, and keeps causing random build failures with noarch64. The only remaining Firedancer usages of FD_HAS_INT128 gates decide whether to use uint128 arithmetic (due to HW support) or whether to soft-emulate.
This reverts commit 04dd4b4.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
ImplicitIntegerTruncation.qlthat detects implicit narrowing conversions between integer types without explicit casts (e.g.ulong→uchar), including integer-promotion artifacts from small literalsfilter.qllto support both production and CodeQL test databases: production DBs have paths prefixed withsrc/, while test DBs use bare filenames with no directory component — previously tests would find zero results because the path filter excluded all test filesLargeMemset.expected: error messages forfd_memsetcalls incorrectly said "call to memset" instead of "call to fd_memset"TrivialMemcpy.expected: line numbers shifted by 2 to reflect current test file contentChanged Files
contrib/codeql/lib/filter.qll— path filter fix for test databasescontrib/codeql/src/nightly/ImplicitIntegerTruncation.ql— new query (added)contrib/codeql/test/query-tests/ImplicitIntegerTruncation/ImplicitIntegerTruncation.c— new test (added)contrib/codeql/test/query-tests/ImplicitIntegerTruncation/ImplicitIntegerTruncation.expected— new expected output (added)contrib/codeql/test/query-tests/ImplicitIntegerTruncation/ImplicitIntegerTruncation.qlref— new query ref (added)contrib/codeql/test/query-tests/LargeMemset/LargeMemset.expected— correctedfd_memsetmessage textcontrib/codeql/test/query-tests/TrivialMemcpy/TrivialMemcpy.expected— updated line numbersBackground — why this matters
config/extra/with-brutality.mkenables-Werror -Wconversion, which would reject all implicit narrowing at compile time. However, brutality builds are not wired into CI — they are local-discipline only. As a result, implicit integer truncations can silently enter the codebase and go undetected. This query fills that gap in the nightly CodeQL pipeline.Tests
ImplicitIntegerTruncationquery is covered by a full inline-expectations test (.c+.expected+.qlref) covering return truncation, variable initialisation, integer literal narrowing, function-call argument truncation, and struct-member assignmentLargeMemsetandTrivialMemcpyexpected files updated to match current query outputTwo real instances in the codebase were modified to introduce
ulong → ucharnarrowing:fd_shred_tile.c:1403:uchar has_contact_info_in = 0UL;fd_sock_tile.c:261:uchar mcast_ttl = 64UL;The
ULsuffix makes the literal typeunsigned long(8 bytes), creating an implicit truncation touchar(1 byte).FAILED: contrib/codeql/test/query-tests/ImplicitIntegerTruncation/ImplicitIntegerTruncation.qlref
The test fails because the query finds the two new patterns but the
.expectedfile does not list them — confirming the query catchesulong-literal →ucharnarrowing correctly. Restoring the original= 0/= 64values and updating.expectedrestores all tests to passing.Type of Change
Notes
The
ImplicitIntegerTruncationquery intentionally includes integer-promotion artifacts (e.g.uchar c = a + bwherea + bisintdue to C integer promotion). Suppressions are done via explicit casts. The query excludesbooltypes and macro expansions to reduce noise.