From: Torbjorn SVENSSON <torbjorn.svensson@foss.st.com>
To: Nick Alcock <nick.alcock@oracle.com>,
Alan Modra <amodra@gmail.com>, Yvan ROUX <yvan.roux@foss.st.com>
Cc: <binutils@sourceware.org>
Subject: Re: [PATCH v2] libctf: ctf_member_next needs to return (ssize_t)-1 on error
Date: Fri, 8 Sep 2023 14:58:04 +0200 [thread overview]
Message-ID: <7f7ea2fb-c690-b48e-bfa8-99ca89690ad7@foss.st.com> (raw)
In-Reply-To: <87wmx2dw0j.fsf@esperi.org.uk>
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.
> 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'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
> 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?
Kind regards,
Torbjörn
next prev parent reply other threads:[~2023-09-08 12:58 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-24 11:32 [PATCH] " Torbjörn SVENSSON
2023-08-25 2:22 ` Alan Modra
2023-08-25 16:53 ` [PATCH v2] " Torbjörn SVENSSON
2023-08-30 8:34 ` Torbjorn SVENSSON
2023-08-30 9:39 ` Alan Modra
2023-09-07 12:10 ` Nick Alcock
2023-09-08 12:58 ` Torbjorn SVENSSON [this message]
2023-09-12 14:23 ` Nick Alcock
2023-09-12 18:44 ` Torbjorn SVENSSON
2023-09-13 9:57 ` [PATCH v3] " Torbjörn SVENSSON
2023-09-13 18:37 ` Nick Alcock
2023-09-13 20:20 ` Torbjorn SVENSSON
2023-09-20 17:44 ` Torbjorn SVENSSON
2023-09-26 14:51 ` Nick Alcock
2023-09-26 17:28 ` [PATCH v4] " Torbjörn SVENSSON
2023-09-26 17:49 ` [PATCH v3] " Torbjorn SVENSSON
2023-09-28 16:41 ` Nick Alcock
2023-09-29 12:11 ` Torbjorn SVENSSON
2023-10-02 10:57 ` Nick Alcock
2023-10-03 12:59 ` Torbjorn SVENSSON
2023-10-03 20:53 ` Nick Alcock
2023-10-05 8:39 ` [PATCH v5] libctf: Sanitize error types for PR 30836 Torbjörn SVENSSON
2023-10-09 10:27 ` Nick Alcock
2023-10-09 14:44 ` [PATCH v6] " Torbjörn SVENSSON
2023-10-09 15:11 ` [PATCH v7] " Torbjörn SVENSSON
2023-10-11 11:14 ` Nick Alcock
2023-10-13 14:01 ` [PATCH] libctf: check for problems with error returns Nick Alcock
2023-10-13 18:31 ` Torbjorn SVENSSON
2023-10-15 19:18 ` Nick Alcock
2023-10-16 12:51 ` [PATCH v8] libctf: Sanitize error types for PR 30836 Torbjörn SVENSSON
2023-10-17 15:15 ` Nick Alcock
2023-10-17 15:35 ` Torbjorn SVENSSON
2023-10-17 18:54 ` [PATCH] libctf: Return CTF_ERR in ctf_type_resolve_unsliced " Torbjörn SVENSSON
2023-10-17 19:40 ` Nick Alcock
2023-10-18 7:40 ` Torbjorn SVENSSON
2023-10-20 17:01 ` Nick Alcock
2023-10-16 13:02 ` [PATCH] libctf: check for problems with error returns Torbjorn SVENSSON
2023-10-17 14:45 ` Nick Alcock
2024-01-30 12:46 ` Andreas Schwab
2024-01-30 14:22 ` Nick Alcock
2024-01-30 14:27 ` Andreas Schwab
2024-03-09 2:44 ` Sam James
2024-03-11 15:14 ` Nick Alcock
2024-03-12 6:52 ` Sam James
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7f7ea2fb-c690-b48e-bfa8-99ca89690ad7@foss.st.com \
--to=torbjorn.svensson@foss.st.com \
--cc=amodra@gmail.com \
--cc=binutils@sourceware.org \
--cc=nick.alcock@oracle.com \
--cc=yvan.roux@foss.st.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).