[PATCH v2] libctf: ctf_member_next needs to return (ssize_t)-1 on error

[Nick Alcock]

On 8 Sep 2023, Torbjorn SVENSSON told this:

> On 2023-09-07 14:10, Nick Alcock wrote:
>> On 30 Aug 2023, Alan Modra via Binutils outgrape:
>> 
>>> On Wed, Aug 30, 2023 at 10:34:05AM +0200, Torbjorn SVENSSON wrote:
>>>> @Alan, any additional comments on this updated patch (except the missing
>>>> semicolon that I mention below)?
>>>
>>> I'm leaving it to Nick Alcock to decide what to do here.
>> I agree that we should indeed be returning -1 from all functions that
>> return an int (it used to, but ctf_id_t has to be an unsigned long). But
>> I think it might be less disruptive to do so via a new
>> ctf_set_errno_int() which is just like ctf_set_errno but returns an int
>> rather than an unsigned long. That eliminates a lot of {}ery and makes
>> each individual hunk smaller.
>
> Ok, I can do that instead if that's considered the proper way.

I think it might be a good bit neater and a good bit less work :)

>> My concern is that it's really hard to validate all this -- can anyone
>> think of a trick that would emit *consistent* warnings if we called
>> return (ctf_set_errno()) from a function returning int? I mean this
>> returning-int thing is a change I made ages ago, and despite making it
>> *and* attempting to validate on 64-bit Windows I have clearly not got it
>> right because it's drifted right out of correctness again.
>>
>> (Similarly, does anyone have a build/target triplet on which this goes
>> wrong? because it's not going wrong on any of my mingw64 or cygwin tests
>> as far as I can tell.)
>
> I discovered the issue using the GCC12 package for arm-none-eabi that Arm released
> (https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads), but built using the x86_64-w64-mingw GCC compiler on Linux.

I'm wondering what the configure options were for binutils itself --
anything? was it a cross at all? (I'll admit this description has
confused me a bit: is this a cross from mingw64 to aarch64 or what?)

> I've opened a ticket for the issue where I've attached 2 object files that you can use to reproduce the issue without needing to
> rebuild GCC + multlibs to verify the problem.
> https://sourceware.org/bugzilla/show_bug.cgi?id=30836

Thanks! I hope I won't need them, but they might well come in handy...

>> I kinda wish we could rely on having C11 -- type-generic macros are made
>> for cases like this :(
>
> Looks like it would be a nice fix indeed, but is there anything else
> that could be done to improve the situation without needing to go to
> C11?

I've been trying to think of something other than adding whatever the
build is you saw this on to my regular test matrix.

-- 
NULL && (void)