@yuwata I initially only fixed the p.names check at line 651. After further review, the same bug exists for p.addresses at lines 267 and 432— both fields are declared as SD_JSON_VARIANT_ARRAY in the dispatch table, so the same is_blank_object → is_blank_array fix applies. I've updated the commit to include all three callsites.

Claude review of PR #42610 (9fc9b4c)

The core fix is correct and complete: sd_json_variant_is_blank_array() returns true for NULL/JSON-null/empty-array and matches the SD_JSON_VARIANT_ARRAY declarations of addresses and names, so the empty-[] case that slipped past is_blank_object() is now diverted to not_found/no_data. All three (and only three) affected callsites are converted, and the r_aliases[n_names-1] underflow is fully resolved. Two maintainer approvals already on record.

All robustness and h_errno-consistency gaps raised in earlier review rounds are now addressed: the added if (n_addresses == 0) guards in gethostbyname4_r/gethostbyname3_r close the all-filtered NULL-deref, and the gethostbyname3_r blank-array guard now routes to no_data, so both of its zero-result paths report NO_DATA consistently.

Suggestions

• gethostbyname4_r still NULL-derefs on all-filtered addresses — src/nss-resolve/nss-resolve.c:267 — non-empty array with no AF_INET/AF_INET6 entries passes the guard but yields n_addresses==0, leaving r_tuple NULL at the assert / r_tuple->next write.
• gethostbyname3_r blank-array path still returns HOST_NOT_FOUND — src/nss-resolve/nss-resolve.c:435 — changing line 458 to NO_DATA left the sibling blank-array guard at HOST_NOT_FOUND; for a family-specific query both conditions mean "name resolved, no record of this family", so this case should also goto no_data for consistency.

Nits

• gethostbyname3_r returns SUCCESS with zero addresses — src/nss-resolve/nss-resolve.c:432 — same all-filtered pattern; harmless but returns NSS_STATUS_SUCCESS with an empty list instead of NSS_STATUS_NOTFOUND.
• gethostbyname3_r NOTFOUND uses HOST_NOT_FOUND not NO_DATA — src/nss-resolve/nss-resolve.c:458 — for the all-filtered case the name resolved but has no record of the requested family; the gethostby* contract classifies that as NO_DATA/NO_ADDRESS rather than HOST_NOT_FOUND. Consistent with the pre-existing empty-array handling, not a regression.
• Early blank-array check now redundant with the n_addresses==0 guard — src/nss-resolve/nss-resolve.c:290 — in gethostbyname4_r (and gethostbyname3_r at line 458) the early is_blank_array check targets the same label as the new post-loop guard, so it is technically redundant; optional cleanup, keeping it for symmetry with gethostbyaddr2_r is equally fine.

Workflow run

@bluca Done, added if (n_addresses == 0) goto not_found; after the counting loop in both gethostbyname4_r and gethostbyname3_r paths. Thank you for the review!

Completed. Please review.