From 9233ee5175f1669bb6e0fbbd775345d8a13819e3 Mon Sep 17 00:00:00 2001 From: Stoian Ivanov Date: Wed, 10 Jun 2026 23:59:43 +0300 Subject: [PATCH] Fix -Wmaybe-uninitialized warning in js_binary_logic_slow GCC (observed with 16.1) cannot prove that buf2 is initialized on the BigInt shift path: js_bigint_get_si_sat(p2) is inlined and reads buf2.tab via js_bigint_sign(), but GCC loses track of the preceding js_bigint_set_short(&buf2, op2) store. The read is in fact always safe. A declaration initializer (JSBigIntBuf buf2 = {0};) does not help because the slow_big_int: label is reachable via goto, which jumps over the initializer. Zero-initialize buf2 with memset() just after the label so it runs on every entry path. --- quickjs.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/quickjs.c b/quickjs.c index 11caae0e3..619bbbdc5 100644 --- a/quickjs.c +++ b/quickjs.c @@ -15324,6 +15324,11 @@ static no_inline __exception int js_binary_logic_slow(JSContext *ctx, JSBigInt *p1, *p2, *r; JSBigIntBuf buf1, buf2; slow_big_int: + /* buf2 is zero-initialized here (after the label, so it also runs on + the goto slow_big_int paths) to silence a -Wmaybe-uninitialized + false positive: GCC cannot prove buf2 is initialized through the + inlined js_bigint_get_si_sat() -> js_bigint_sign() read below. */ + memset(&buf2, 0, sizeof(buf2)); if (JS_VALUE_GET_TAG(op1) == JS_TAG_SHORT_BIG_INT) p1 = js_bigint_set_short(&buf1, op1); else