lib: add bf_vector and use it in cgen

[pzmarzly]

I initially planned to use bf_vector in bf_hashset, but I got convinced by @yaakov-stein that it's not a good idea. However, we could use bf_vector in other places, especially where we use bf_dynbuf or where we handroll vector-like behavior.

Commits:

• lib: core: add bf_vector - implementation. Vector doubles in size when it hits the limits. Has a helper to remove elements as well, though shrinking is not implemented.
• cgen: use bf_vector for img - Instead of managing img, img_size, and img_cap by hand, use bf_vector.

[github-actions]

Claude review of PR #487 (0926237)

Suggestions

• Overflow guard in bf_vector_add — src/libbpfilter/core/vector.c:165 — vec->size + 1 can theoretically wrap; bf_vector_add_many already uses __builtin_add_overflow for the same pattern
• Missing test for bf_vector_init — tests/unit/libbpfilter/core/vector.c — public function only tested indirectly via bf_vector_new
• Orphaned instruction on fixup failure — src/libbpfilter/cgen/program.c:511 — EMIT runs before bf_fixup_new in both bf_program_emit_fixup and bf_program_emit_fixup_elfstub; if fixup creation fails after a successful emit, an un-patched placeholder instruction remains in the image
• Large initial reservation without rationale — src/libbpfilter/cgen/program.c:119 — bf_vector_reserve(&_program->img, 512) is 8x larger than the old default of 64; consider a named constant and/or comment
• void * pointer arithmetic in bf_vector_foreach — src/libbpfilter/include/bpfilter/core/vector.h:65 — arithmetic on void * is a GCC extension, not valid ISO C; downstream consumers using -pedantic will get a compilation error

Nits

• _end naming convention — src/libbpfilter/include/bpfilter/core/vector.h:66 — should use __end to match __next/__r/__idx pattern in other macros
• _BF_VECTOR_MAX_CAP comment — src/libbpfilter/core/vector.c:16 — says "multiplying by 1.5x" but growth uses cap + cap / 2
• bf_vector_clean doc omits elem_size behavior — src/libbpfilter/include/bpfilter/core/vector.h:89 — elem_size is preserved after clean; the doc should mention this so callers know bf_vector_add works without re-initialization

CLAUDE.md improvements

• The style guide says "Only use assert() for pointer values" but the codebase uses assert for non-pointer validation in several places (e.g., bf_vector_default asserts elem_size > 0). Consider documenting when non-pointer asserts are acceptable (e.g., for by-value return APIs).
• Double-underscore identifiers (__next, __end, __r, __idx) in macros are technically reserved by the C standard (C17 7.1.3). This is an established pattern in the codebase; consider documenting it as an accepted convention.

Workflow run

[github-actions]

Claude: suggestion: bf_vector_foreach performs pointer arithmetic on void * ((elem) + (vec)->elem_size and (vec)->data + ...), which is a GCC extension not valid in standard C.

Since vector.h is a public header under include/bpfilter/core/, any downstream consumer using this macro with -pedantic -std=c17 will get a compile error. The pedantic integration test (tests/integration/pedantic_c.sh) includes all public headers with -pedantic-errors -std=c17 -Werror — the macro definition alone won't trigger an error (unexpanded macros aren't compiled), but any call site under those flags will fail.

For comparison, bf_list_foreach in list.h avoids this by iterating over typed pointers (bf_list_node *). Consider casting through char *:

Suggested change

	/**
	#define bf_vector_foreach(vec, elem) \
	for (void *(elem) = (vec)->data; \
	(elem) && (char *)(elem) < (char *)(vec)->data + ((vec)->size * (vec)->elem_size); \
	(elem) = (void *)((char *)(elem) + (vec)->elem_size))

[pzmarzly]

We could do that, but the codebase is already not C17 compliant in different places as well.

[qdeslandes]

Do not add

This should not be an issue.

remove elements during iteration

Same here, as we don't shrink the memory buffer.

[pzmarzly]

Do not add

If that addition causes growth/reallocation, void *(elem) = (vec)->data; will point to the old memory address. I could turn the iterator into index int i = 0; and use double-for trick to have void *(elem) = (vec)->data + i * (vec)->elem_size;, but I think it's an overkill?

remove elements during iteration

But we shift the next elements left, i.e. 5th element becomes 4th, 4th becomes 3rd, etc. The foreach will skip an element because of (elem) = (elem) + (vec)->elem_size.

[github-actions]

Claude: suggestion: The initial reservation of 512 instructions (512 * sizeof(struct bpf_insn) = 4 KiB) is 8x larger than the old _BF_PROGRAM_DEFAULT_IMG_SIZE of 64. This may be an intentional tuning improvement to reduce early reallocations, but the rationale is not documented. Consider defining a named constant (like the removed _BF_PROGRAM_DEFAULT_IMG_SIZE) and adding a brief comment explaining the sizing choice.

[github-actions]

Claude: nit: The bf_vector_clean documentation says the vector can be "reused (e.g. by re-assigning via bf_vector_default)" but does not mention that elem_size is preserved. Since bf_vector_add works correctly on a cleaned vector without re-initialization, consider noting that elem_size is retained, so callers know whether they need to call bf_vector_default/bf_vector_init again.

[pzmarzly]

They should call init / default nonetheless. We can be permissive in case they forgot, but then we shouldn't document it.