[JDarnley]

udict_inline_shorthand() accepted the type just after the last
shorthand and read one entry past the table, which udict_name() then
returned. Mark the end of the shorthand types in enum udict_type, and
check in udict_inline_test that every shorthand has a name and that the
marker is rejected.

[JDarnley]

What claude said when it helped me diagnose the CI failure of some other code I want a PR for

The cause is an off-by-one in upipe itself, in udict_inline_shorthand() in lib/upipe/udict_inline.c, which dates from commit 75c69fe (“optimize udict”). With N shorthand types, the valid types are UDICT_TYPE_SHORTHAND + 1 to UDICT_TYPE_SHORTHAND + N. The check only rejected types above UDICT_TYPE_SHORTHAND + 1 + N, so type UDICT_TYPE_SHORTHAND + N + 1 read one entry past the end of inline_shorthands.

Why it shows up now: uref_sub_shorthand(), from the original uref_sub commit, looks for a shorthand by asking udict_name() about each type in turn until the call fails. Every time it doesn’t find one, it ends up asking for exactly that out-of-range type. So any extraction of a per-entry attribute that has no shorthand triggers it