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 260733858C66 for ; Tue, 26 Sep 2023 17:49:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 260733858C66 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 38QBbs4b007893; Tue, 26 Sep 2023 19:49:47 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h= message-id:date:mime-version:subject:to:cc:references:from :in-reply-to:content-type:content-transfer-encoding; s= selector1; bh=gACuhMJ+JxlEGsAsiJnVHY/oNVmsPLZP11pRWEmWh5Q=; b=66 dTTvt5S2NJC+IDcV38LEww6omoMgGfXcpcDIpysEbC4+AhLUZDzEKn03dhOfXD9o Re9PAMqQfkrrHNtOFIoa5tYGtXqtW+wrcwVE7LsiCM18nMY3ZfoZEb7PinfmNrmB 9xSaGcst71/YAfDrWHW9ePd7Sp4TJ6mw6hOGDINAKuqKEF/HxYy5M7ewOKEzf/6J Rw2xlCkO50pOjHasmO2ICandKv5GwHQ2uPKetvzveOMG3FbqMTX6AYbPvTlqAX12 Jq482uF7dciyAW4LHmZUT98bY75cI49XFowMN0Y5B3Bh6dVIRmfOXUiFRTazOhJR ZHsYOSohl1rjpVyt0tRg== 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 3t9qbwwhck-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Sep 2023 19:49:47 +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 F1830100069; Tue, 26 Sep 2023 19:49:35 +0200 (CEST) Received: from Webmail-eu.st.com (shfdag1node3.st.com [10.75.129.71]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id E91D926D2AC; Tue, 26 Sep 2023 19:49:35 +0200 (CEST) Received: from [10.74.18.1] (10.74.18.1) 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; Tue, 26 Sep 2023 19:49:35 +0200 Message-ID: Date: Tue, 26 Sep 2023 19:49:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] libctf: ctf_member_next needs to return (ssize_t)-1 on error To: Nick Alcock CC: , , Yvan ROUX References: <878r9ba2sf.fsf@esperi.org.uk> <20230913095727.1420654-1-torbjorn.svensson@foss.st.com> <87a5tp2a3n.fsf@esperi.org.uk> <657dadf8-4b7b-67e6-9de2-9a1cdb79f081@foss.st.com> <87wmwdt2bf.fsf@esperi.org.uk> Content-Language: en-US From: Torbjorn SVENSSON In-Reply-To: <87wmwdt2bf.fsf@esperi.org.uk> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.74.18.1] X-ClientProxiedBy: SHFCAS1NODE1.st.com (10.75.129.72) To SHFDAG1NODE3.st.com (10.75.129.71) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.267,Aquarius:18.0.980,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-09-26_13,2023-09-26_01,2023-05-22_02 X-Spam-Status: No, score=-5.1 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-26 16:51, Nick Alcock wrote: > On 13 Sep 2023, Torbjorn SVENSSON outgrape: >> On 2023-09-13 20:37, Nick Alcock wrote: >>> On 13 Sep 2023, Torbjörn SVENSSON verbalised: > Honestly I suspect all we need is a better name: > > ctf_set_int_errno(...); > ctf_set_type_errno(...) > > and then use one or the other, consistently. (Neither needs to call the > other: they're only two lines long!) Ok. I've updated the patch (V4) to be like you suggested above. > >> I suppose the ctf_set_errno_unsigned could even be a macro in the ctf-impl.h header file. > > I'd make both of them inline functions personally (I bet it would reduce > code size!) I do not see any major difference in code size for the ld.exe binary after the change. > >>>> +int >>>> +ctf_set_errno_signed (ctf_dict_t *fp, int err) >>>> +{ >>>> + fp->ctf_errno = err; >>>> + /* Don't rely on CTF_ERR here as it will not properly sign extend on 64-bit >>>> + Windows ABI. */ >>>> + return -1; >>>> +} >>> ... that Windows is not really the problem here. It's more >>> /* Don't rely on CTF_ERR here; it is a ctf_id_t (unsigned long), and >>> it will be truncated to a non--1 value on platforms on which int >>> and unsigned long are different sizes. */ >>> perhaps? (At least, I think that's what's going on.) >> >> The problem happens when the signed integral type is wider than unsigned long. > > ... sizeof(signed int) > sizeof(unsigned long int)?! Is that even > possible? I would have assumed from the C type hierarchy and the integer > conversion rank rules would have required that unsigned long int was at > least as big as any non-long integral type, but I don't see anywhere > it's required in the standard, dammit... I don't know about the 'sizeof(signed int) > sizeof(unsigned long int)' part, but what I said was _integral type_, not _int_. In the case where I saw the problem, it was ssize_t but I'm not sure what that maps to, but it's wider than unsigned long int apparently in this case. >>> This probably needs testing on a wide variety of platforms with >>> different type sizes. I'll add throwing this through my entire test >>> matrix to my todo list, and fix any bugs observed: but the basic idea >>> looks sound to me. >> >> Do you want to run this full matrix before or after submitting the patch? >> If it's before; when do you think you will have time to do that? >> >> Let me know how you want to proceed. > > OK, I'm back from various conferences so I can throw tests past this at > any time, it's largely automated. So once I stop faffing about and > changing my mind and we converge on something I'll throw it past every > test I've got. (It takes a day or so.) If you do not see any problem with the V4 patch, then please go ahead and run the tests that you have to get a verdict. Kind regards, Torbjörn