From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx07-00178001.pphosted.com (mx07-00178001.pphosted.com [185.132.182.106]) by sourceware.org (Postfix) with ESMTPS id A2E853858D1E for ; Fri, 8 Sep 2023 12:58:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A2E853858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=foss.st.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=foss.st.com Received: from pps.filterd (m0241204.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.17.1.22/8.17.1.22) with ESMTP id 388AN6AL031227; Fri, 8 Sep 2023 14:58:06 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h= message-id:date:mime-version:subject:references:from:to:cc :in-reply-to:content-type:content-transfer-encoding; s= selector1; bh=sq3NKea5qMTogdiMFWM5FoNctD17QkgQgebzREUvQW0=; b=Wt BM1Y1XLF/nnignpwgDSFNzl2echLVzc3kW1UcC9rx1dcVJ7riS3tzOOdQM5QRSi8 yWTcJUX7s6d3h1eqUW4F8dyPX5F/cEt9nLiwTHalWcue2VtN1g5xf/47Uk1tJOnt onxs1OgmIHkQ7Dg5XGKHP7bAk1U79t832PisJRgidcyPrnqXO+kFoU5ik9vpOgGw Ub6kG4QVwtihD78XLaEwqkvidDTnN9PehHnR6mNA6CtPqYo/jKUn7Mijqgn0FMvT VS07ryASz7+TD/z8KxTcKu9TPrtBOoWBEbVSv4qlf5kyE4kkiDDbH0/0DN71/7AY 12otlCH2Bt3w+6aSHs8w== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com (PPS) with ESMTPS id 3suvd12y19-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 08 Sep 2023 14:58:06 +0200 (MEST) Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 825F9100052; Fri, 8 Sep 2023 14:58:05 +0200 (CEST) Received: from Webmail-eu.st.com (shfdag1node3.st.com [10.75.129.71]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 7B98027F331; Fri, 8 Sep 2023 14:58:05 +0200 (CEST) Received: from [10.131.139.243] (10.131.139.243) by SHFDAG1NODE3.st.com (10.75.129.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Fri, 8 Sep 2023 14:58:05 +0200 Message-ID: <7f7ea2fb-c690-b48e-bfa8-99ca89690ad7@foss.st.com> Date: Fri, 8 Sep 2023 14:58:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] libctf: ctf_member_next needs to return (ssize_t)-1 on error References: <20230825165333.34510-1-torbjorn.svensson@foss.st.com> <54adb46a-aaf6-2dbf-9df1-f7fd857dac7d@foss.st.com> <87wmx2dw0j.fsf@esperi.org.uk> Content-Language: en-US From: Torbjorn SVENSSON To: Nick Alcock , Alan Modra , Yvan ROUX CC: In-Reply-To: <87wmx2dw0j.fsf@esperi.org.uk> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.131.139.243] X-ClientProxiedBy: SHFCAS1NODE2.st.com (10.75.129.73) To SHFDAG1NODE3.st.com (10.75.129.71) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.267,Aquarius:18.0.957,Hydra:6.0.601,FMLib:17.11.176.26 definitions=2023-09-08_09,2023-09-05_01,2023-05-22_02 X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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