On 10/14/26 2:32 PM, Brad Smith wrote:
On 2026-10-05 5:58 a.m., Niels Möller wrote:
Brad Smithbrad@comstyle.com writes:
elf_aux_info() returns an errno value (0 on success) rather than -1 with errno set. Ignoring the return value means the result is unreliable on failure. Treat a failure as "no features reported" so the generic code is used.
The variables are explicitly initialized to zero. I would expected that elf_aux_info leaves them unchanged on failure, i.e., they stay zero.
So I'm curious both on the conditions that might make an elf_aux_info call for AT_HWCAP or AT_HWCAP2 fail, and if it really clobbers the output buffer on failure (which seems like a rather rude api to me)?
I was specifically asked by another FreeBSD/OpenBSD developer to instate the error checking as the contract with the API does not guarantee not writing to the buffer.
I specifically made a comment along the lines you did and was told..
"That's an implementation detail, not an API guarantee."
That makes more sense. The initial "patch" came through with a description and just some ASCII art arrows, not really a patch, and that was a bit vague for me.
Are there three discrete things going on here? 1. The possibility of the output buffer for elf_aux_info being clobbered on error 2. The lack of error checking on the return value for elf_aux_info 3. The need for hwcaps2
Is that right?
It's also not clear what they need from hwcaps2 to enable what feature.
Anyway to just clear this up and get a patch series for this?
Thanks, Bill