Suppress spurious -Wcast-align in the arena allocator

[brtnfld]

cell_realloc()'s header-before-payload pattern and its call sites that cast the returned char* back to a wider-aligned pointer type trigger -Wcast-align under -Werror. The casts are safe: p is always either REALLOC()'s own return value, or p - sizeof(cell_t) recovers that exact same, maximally-aligned pointer -- the compiler just can't prove it from byte-level pointer arithmetic on a char*. Route each cast through an intermediate (void *), the standard idiom for a deliberate alignment-increasing cast. No behavioral change.

[cktan]

can't repro

[brtnfld]

Re "can't repro": the warning only shows up if -Wcast-align is explicitly enabled — it's not part of -Wall/-Wextra, and the project's default src/Makefile CFLAGS (-std=c17 -Wmissing-declarations -Wall -Wextra -MMD) don't turn it on, so a plain make won't trigger it.

Steps to reproduce (against main before this PR):

git checkout main -- src/tomlc17.c
cc -std=c17 -Wall -Wextra -Wcast-align -Werror -c src/tomlc17.c -o /tmp/t.o

That fails with 8 -Wcast-align errors, e.g.:

src/tomlc17.c:224:16: error: cast from 'char *' to 'cell_t *' (aka 'struct cell_t *') increases required alignment from 1 to 4 [-Werror,-Wcast-align]
  cell_t *cp = (cell_t *)(p - sizeof(cell_t));

Building the same command against this branch's src/tomlc17.c compiles clean.

I also rebased the branch onto the latest main (your recent "cleanup" commit had reformatted a couple of the same lines this PR touches, which was causing the merge conflict) and re-verified with the -Wcast-align -Werror build plus make test (all suites pass except stdtest, which needs go/toml-test not installed in my sandbox — unrelated to this change). PR should be mergeable now.

[cktan]

i don't see it on ubuntu...

[cktan]%
[cktan]% cc -std=c17 -Wall -Wextra -Wcast-align -Werror -c src/tomlc17.c -o /tmp/t.o
[cktan]%

[brtnfld]

Found it -- we're both right, and it's the compiler.

-Wcast-align is not implied by -Wall/-Wextra, and gcc's plain
-Wcast-align is a no-op on x86-64: gcc only reports it on targets that
genuinely require the stricter alignment. clang reports it on any target.
So cc -Wcast-align is silent when your cc is gcc on x86-64, and noisy
when mine is clang. That's the whole disagreement. Sorry -- I should have
said which compiler I was using instead of just pasting the command.

Measured on the commit before the fix:

gcc   -Wall -Wextra -Wcast-align           ->  0 diagnostics
gcc   -Wall -Wextra -Wcast-align=strict    ->  8 diagnostics
clang -Wall -Wextra -Wcast-align           ->  8 diagnostics

and on this branch, all three report 0.

To reproduce on your Ubuntu box without installing anything, add =strict:

gcc -std=c17 -Wall -Wextra -Wcast-align=strict -Werror -c src/tomlc17.c -o /dev/null

Rather than leave that buried in this thread, I've pushed a CI job
(029dc93) that runs both spellings with -Werror, so it is reproducible
on either compiler and any regression shows up as a failing check. I
checked the job's exact commands pass on the fix commit and fail on its
parent, so it isn't vacuous.

Also rebased onto current main -- the branch had fallen ten commits
behind. The merge is clean and none of the intervening commits introduced
new cast sites, so the fix is still complete: the merged tree reports 0
under both gcc -Wcast-align=strict and clang -Wcast-align.

Entirely reasonable to take the CI job and skip the source change if you
would rather not carry the (void *) casts -- though then the job would
need to come out too, since it would fail on main as it stands.