commit 042eb011bb367ab2845535914ec40a570d114ace parent 0628fd75103a9c5159a6b384f25fa78a5a64abb4 Author: Ryan Sepassi <rsepassi@gmail.com> Date: Mon, 11 May 2026 08:31:47 -0700 test/parse: sizeof / nonzero subscript on direct string literal Cover the two TOK_STR lowering gaps in parse_primary: sizeof("abcd") must yield 5 (char[N] not char*), and "ab"[1] must yield 'b' (subscript on a literal at a nonzero index). Diffstat:
4 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/test/parse/cases/6_5_22b_sizeof_string_literal.c b/test/parse/cases/6_5_22b_sizeof_string_literal.c @@ -0,0 +1,7 @@ +/* sizeof on a string literal should yield the size of its char-array + * type per C11 §6.5.3.4 / §6.4.5 — sizeof("abcd") is 5 (4 bytes + NUL). + * Today parse_primary materializes the literal as a `char*` rvalue, so + * sizeof reports pointer size (8 on LP64) instead of the array size. */ +int test_main(void) { + return (int)sizeof("abcd"); +} diff --git a/test/parse/cases/6_5_22b_sizeof_string_literal.expected b/test/parse/cases/6_5_22b_sizeof_string_literal.expected @@ -0,0 +1 @@ +5 diff --git a/test/parse/cases/6_5_32b_string_subscript_nonzero.c b/test/parse/cases/6_5_32b_string_subscript_nonzero.c @@ -0,0 +1,8 @@ +/* Subscripting a string literal at a nonzero offset should yield the byte + * at that offset. Today the parser/cg path returns 0 for any index > 0 + * even though `"ab"[0]` and the same byte via `char s[] = "ab"; s[1]` + * both work — the limitation is specific to a direct TOK_STR subscript + * with a nonzero index. */ +int test_main(void) { + return "ab"[1]; /* 'b' = 98 */ +} diff --git a/test/parse/cases/6_5_32b_string_subscript_nonzero.expected b/test/parse/cases/6_5_32b_string_subscript_nonzero.expected @@ -0,0 +1 @@ +98