codegen: a local io value used only by built-in methods leaves its `v_` pointer unused, failing -Wall -Werror
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 76/100
Research direction
Read internal/cgen/var.go around writeVars (lines 334–383), where the issue says the local IO pointers are declared. Mark the generated v_ pointer as potentially unused, matching the neighboring pointers. Reproduce with the provided Wuffs example, generate C, and compile it with -std=c99 -Wall -Werror; done when gcc and clang no longer report unused-variable errors.
Written by the indexing model from the issue text.
Description
Hi,
General context of this work is in #188, including the AI-disclaimers.
No in-tree codec is affected by this issue; each of std's ten local io values, in std/gif, std/jpeg, std/lzma and std/png, is used by an io_bind, which uses its v_ pointer. Claude judges the prospective risk of it as "low": an unused-variable warning causes compilation to fail under -Werror.
The following is Sol 6.1's writeup of the issue. Includes a repro, generated C, gcc 13.3, clang 18 and MSVC compile results, compiler diagnostics for a related discarded-result variant, and a scan of std's local io values. The cause is reasoned from source.
For a local io_writer or io_reader named w, cgen declares a wuffs_base__io_buffer u_w, a pointer v_w to it, and four pointers marked WUFFS_BASE__POTENTIALLY_UNUSED: iop_v_w, io0_v_w, io1_v_w and io2_v_w. Built-in io methods use only those four pointers. A local used only by built-in methods, outside any io_bind, therefore leaves v_w unused.
Minimal repro:
pub struct tester?(
n : base.u64,
)
pub func tester.f?() {
var w : base.io_writer
var r : base.io_reader
this.n = w.length() ~mod+ r.length()
w.write_u8?(a: 1)
}
Actual: at b36a81d3, wuffs-c gen -package_name repro repro.wuffs exits 0 with empty stderr and declares:
wuffs_base__io_buffer u_w = wuffs_base__empty_io_buffer();
wuffs_base__io_buffer* v_w = &u_w;
uint8_t* iop_v_w WUFFS_BASE__POTENTIALLY_UNUSED = NULL;
uint8_t* io0_v_w WUFFS_BASE__POTENTIALLY_UNUSED = NULL;
uint8_t* io1_v_w WUFFS_BASE__POTENTIALLY_UNUSED = NULL;
uint8_t* io2_v_w WUFFS_BASE__POTENTIALLY_UNUSED = NULL;
With -std=c99 -Wall -Werror, as build-all.sh uses for the release snapshot, gcc 13.3 and clang 18 both fail with exit code 1; MSVC /W3 compiles it:
iolocal-release.c:26179:26: error: unused variable ‘v_w’ [-Werror=unused-variable]
iolocal-release.c:26185:26: error: unused variable ‘v_r’ [-Werror=unused-variable]
iolocal-release.c:26179:26: error: unused variable 'v_w' [-Werror,-Wunused-variable]
iolocal-release.c:26185:26: error: unused variable 'v_r' [-Werror,-Wunused-variable]
Outside an io_bind, the local has no buffer, so w.write_u8? always suspends; the Wuffs program is still valid.
Expected: declare v_w with WUFFS_BASE__POTENTIALLY_UNUSED, like the pointers next to it.
Cause: writeVars declares the io local and its pointers:
A related discarded-result warning belongs with #203's built-in lowerings: args.src.read_u8?() on its own line becomes uint8_t t_0 = *iop_a_src++; followed by t_0;, which gcc rejects with statement with no effect [-Werror=unused-value] and clang with expression result unused [-Werror,-Wunused-value].
- Dominant language
- C
- Stars
- 4.9k
- Forks
- 150
- Avg merge
- 4d 1h
- Merged PRs (30d)
- 3
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from google/wuffs
-
codegen: `io_reader.match7` with an empty prefix shifts a `uint64_t` by 64 and reports a mismatchOpen
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 3/5 1-2 days Newbie friendliness 67/100
-
Difficulty 4/5 3-5 days Newbie friendliness 56/100
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
Maintainers usually reply within 9 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
containers/bubblewrap#826 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 1-3 hours Newbie friendliness 62/100
Revivedx/SavageWindRecomp#488 ·
Maintainers usually reply within 1 day
-
needs-device
Difficulty 2/5 1-3 hours Newbie friendliness 70/100