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 (73c0440)

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

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

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: bf_vector_add passes vec->size + 1 to _bf_vector_grow without overflow protection. If vec->size is SIZE_MAX, this wraps to 0, causing _bf_vector_grow to see required <= vec->cap and return success, after which the memcpy writes past the allocated buffer.

bf_vector_add_many already guards the equivalent addition with __builtin_add_overflow (line 186). The same pattern should be applied here for consistency:

size_t required;
int r;

assert(vec);
assert(elem);

if (__builtin_add_overflow(vec->size, 1, &required))
    return -ENOMEM;

r = _bf_vector_grow(vec, required);

While SIZE_MAX elements is unreachable in practice, the inconsistency between the two functions makes the code harder to reason about.

[github-actions]

Claude: nit: The internal sentinel variable _end uses a single-underscore prefix, while other macros in the codebase consistently use double underscores for internal variables: __next in bf_list_foreach (list.h:107), __r in EMIT (program.h:103), __idx in bf_jmpctx_get (jmp.h:60). Consider renaming to __end to match the established convention.

[github-actions]

Claude: nit: The comment says "Largest number that won't overflow when multiplying by 1.5x" but the growth factor is applied as cap + cap / 2 (integer addition), not a literal multiplication. A more precise comment would be: "Largest capacity where cap + cap / 2 does not exceed SIZE_MAX."