From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by sourceware.org (Postfix) with ESMTPS id 0132A385CC87 for ; Mon, 2 Oct 2023 10:57:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0132A385CC87 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=oracle.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=oracle.com Received: from pps.filterd (m0333520.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3928XRpK006428; Mon, 2 Oct 2023 10:57:33 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : references : date : in-reply-to : message-id : content-type : mime-version; s=corp-2023-03-30; bh=vf1Q2kxqbwmman9bRg8WEWYFGPIooCMnRbO2nus9ehk=; b=xP0d8uPn4W6iaC6ckbxJggq1h85DZ4EjE4PKgNu8ZTDHr2kAE/sSAs54EXAy2cmyi2DE SOs8c1rvLFUf/HYjfFzm2rj4ikUxn0fpu+KOsTZlSNuGLcCTA26w24grRiiJCeLkp8yM gSeYF8s8viOo7NjngxaBhZwhUviW1QKIhvDUB8MhlAn4Odt35QFhLmSGEOYvH72WbXXj fFTVpkKo/tyeUiUhAMDaeM7vLsWOiCcAicJieCqXfq7T4Ylz7VJQB7CtycJL5W6dFwQ6 Kr4hY0hAcUtnTy7p8jAL7u/iBvE9/mI16nTH0jRnZwoot7o2NDc2evUfkEg7nMoPYRQz sg== Received: from iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta03.appoci.oracle.com [130.35.103.27]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3tebqdt82v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 02 Oct 2023 10:57:32 +0000 Received: from pps.filterd (iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 392AWX1a000649; Mon, 2 Oct 2023 10:57:32 GMT Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2102.outbound.protection.outlook.com [104.47.55.102]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3tea44d3f7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 02 Oct 2023 10:57:32 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZNR4b/PxyYRt/8Z79zf3/qbIqBbzgrPfAGqlxnVWCFeHtxMZgil/PCB/y5EfZHIcw8pFWlohwXwMPcNwkI+i7BUr1LIj3DIW7q0TcAlZ90qUrpj41ouvzPeipAOwqDGqkiLRO1a21QoNw79KwR6X3UZw/Mk7JJFeAQyLXnW3YIt5+7h49ymVGohJBZej7d1UAFR5Nktm0lcmlGZdFRYreOxQ91XvTVmECfsmJJncr+vVuD/RKQ+O5Uf3OT+tE0cQCbgCLUkAI4Q+LMa73pFDiyAVrv0blc8H1SPHYfvFAUiXJH4qcUriwRbpT86eJtpVpvSrAzby8qd+eaTNiBi9bA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vf1Q2kxqbwmman9bRg8WEWYFGPIooCMnRbO2nus9ehk=; b=FzZ53Q0/uljSaPglL61q/XTwautHnxMejqgRVrY/Ns5BmdK7DQZD1PJ6NnnO0VYDK7wE+qSW+5oslweyOK+fJl90X0d/WePiPHVdFH0UODf3eRSVNv9hwI5MpizV3dtxQD7rnwU+HYrAbh98pcbEX/JKSO4nR8sPYJPsAhMelbBxaxKGSG6n9srYQbXgtrlJKvtOvV2PZIWCzEnWAn02V4uhj/xp77JaUShGBrA2r2wrCIqJQsCwG1d5QjaYmRi5Pb72Z+Ud5jZte42mVTdLJEOmGXaLVCPTYjf68b44OUOdC/ucqbyP/gq8gmIrmj6Hs24xUk6esUiEaikLftDg8A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vf1Q2kxqbwmman9bRg8WEWYFGPIooCMnRbO2nus9ehk=; b=JaufAZdbe1tyJWGkw76YWy3OUSTR7/2cy1ErsihFjh0smlcglTWD2JpkKV/pYxcLRdSLchvxjuF+vJEpGm0DP5kzzJfqt8J+SHOjo9yt3h8Pb+nkm7RhMPgXNzITi8Lwak9QRPBNpNyM2OiV0Ftac0eL2adMNJaXn+vFUXzTBcw= Received: from DS0PR10MB6798.namprd10.prod.outlook.com (2603:10b6:8:13c::20) by SA2PR10MB4700.namprd10.prod.outlook.com (2603:10b6:806:11c::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6813.19; Mon, 2 Oct 2023 10:57:30 +0000 Received: from DS0PR10MB6798.namprd10.prod.outlook.com ([fe80::d1e:2b9f:3f23:6950]) by DS0PR10MB6798.namprd10.prod.outlook.com ([fe80::d1e:2b9f:3f23:6950%6]) with mapi id 15.20.6838.030; Mon, 2 Oct 2023 10:57:30 +0000 From: Nick Alcock To: Torbjorn SVENSSON Cc: , , Yvan ROUX Subject: Re: [PATCH v3] libctf: ctf_member_next needs to return (ssize_t)-1 on error 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> <87r0mimero.fsf@esperi.org.uk> Emacs: don't cry -- it won't help. Date: Mon, 02 Oct 2023 11:57:22 +0100 In-Reply-To: (Torbjorn SVENSSON's message of "Fri, 29 Sep 2023 14:11:50 +0200") Message-ID: <87ttr9l2b1.fsf@esperi.org.uk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux) Content-Type: text/plain X-ClientProxiedBy: AS4P195CA0007.EURP195.PROD.OUTLOOK.COM (2603:10a6:20b:5e2::7) To DS0PR10MB6798.namprd10.prod.outlook.com (2603:10b6:8:13c::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR10MB6798:EE_|SA2PR10MB4700:EE_ X-MS-Office365-Filtering-Correlation-Id: e780a539-0353-455e-d49b-08dbc3365f48 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ur5EdAuDbT3uQA7LijU6KTijV+ykqwy0diSeNVmt/WFOTI3vpGIoDGkbs93Hs6Eh92kGzkA9XQ8VU+buktL/C960pz8UBQJTbA14uoOYTEA5iT1ZA5YIbB5BayuB+8uoY8TB7CBT6zJX4vTvLZ1b9AQju97mYv9mCZnQ9bMtIMTDucyfw3LEMBtrjMpLpSDE0OMI0o3adhxQtlU8JbYhfiBF+lX0T1UX3PEnbbslpATGEL4m6Z96uHaa4+C+AOK/0OAlK6ycwx0r30ZHDeh4JZ1LhEFvzZCc5IAqCdK9zi5OPTa4hhif5l1Xehc8nivfTBa6VqGgi/9pTh595HkABVw8c7Gz+U3Al4Yby6kyouw1r6LXUL1MZUdi+oEZD2v4z4+gVNqb0vkhBkLUDLqt2vSTjIZ47LhUIacZIS1q9/nhG+1kU6rJMsdnV0U0MNh6bd/uotRBFk6adzNYao+RDfspyQPEHuQRQeAykn2gGS0InKxbURWeyw8VjUBNgOia4MttsY5B2f/eGhbfCvftYjZdmmC45CK/MU4YS/0s4eat4NvIWF9qIvgPm1pmLN3m X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS0PR10MB6798.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(136003)(346002)(39860400002)(376002)(366004)(396003)(230922051799003)(451199024)(186009)(64100799003)(1800799009)(6666004)(478600001)(83380400001)(9686003)(6512007)(6506007)(6486002)(53546011)(86362001)(44832011)(2906002)(5660300002)(8676002)(8936002)(4326008)(38100700002)(66946007)(41300700001)(36756003)(316002)(66476007)(6916009)(54906003)(66556008);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?wZQVfrf01mliT2RIRQawaXtAhyIPQQDRgP1IMcM8omzR7ZWF06bVzYoSiZ6a?= =?us-ascii?Q?hyhM1cgQ1lO6/9HUk1gWONrj2I14VYss0sizw0lqB2mz8HJJZqTyRbQvG+0/?= =?us-ascii?Q?gq8WQGdnCtb4wFIioJD8tvLy4xVgZkiWxRSYEtMTywUtWmllMoLAyNmm5Exf?= =?us-ascii?Q?QtoEd8LqulhKauleFnsKZczkCLIDCpjLxlgpPChzihlAEbds0lQTFehiX3Vi?= =?us-ascii?Q?/07Dd2sSTqmZQORkStGClTEHNUrCOEw92JsOE/UMdCKyOwURMCQnL+2J4AKa?= =?us-ascii?Q?bK0jTTVxPVm2wtAuIa8TnPXbzhjl7bd+29GKqpUQ4Xz4dYowju38CZyK9/r/?= =?us-ascii?Q?KeAdyo1tenEmr3uEz2+9Lp6nIa3Ii3WwBd4sqNZDk6z2u69zEGsuNmVpvUym?= =?us-ascii?Q?XKEPEE/7stYUhLeEhoTnxUGDz6Rmnln2w+Q0mXdMlx9bcKZFCxgo6J64RXgo?= =?us-ascii?Q?ddFnjQIXzFcEwcl2uvNnJqAPUCktkwlGVSAybB2j5h84TlR4mv+/Xhgj+pcK?= =?us-ascii?Q?j0bFNUCPkmMayUhZ6HatD7C9lfQOt4cfp6dXnThJe+Xmap2t0yRgxjPEhZ7Z?= =?us-ascii?Q?5zzzmY1DvDFtO+WEkdrKmCL3Pvl65R/lpf2Wd/If7y6yvUjSM+EV9ZqbnKs6?= =?us-ascii?Q?FSA24O9dCxm5xe+ymxFa4rY+LC8bJXpEg+q4kAvINkVF7DokTNe161l/Yc7M?= =?us-ascii?Q?dnqHaUfayMaqDZxmfJ+9t+8F2RlR54MezNlVEhHsojCx3svEq6aCoEBLH0YE?= =?us-ascii?Q?gkSpumhy11vLqouHzooyUfzbJFO6bOcgpp9l30nwG2peF7sAKVQOZIFbJ2YE?= =?us-ascii?Q?drXIf/0/+LMLFt7zy5ppiQXwONBVINIr+CdawyvJE9JQffwvQd2IoxM65QOA?= =?us-ascii?Q?dKq16ZCSaMTP50n0WZu1UjCLEnvVy/OMQsHDy4ZW8nA5iEXSjVZ74uGu7EZM?= =?us-ascii?Q?+fpaffMzLvLfHN+yC3CPYNGXAs+4RsRK2zrIU3YqBITzqjNXNRJp2kbV2bFp?= =?us-ascii?Q?HC/raIJ+dOJADoMN8hRhHGaWJKfSgO6NtfNarXgxKbRslR+8Cpn1uQFlESKE?= =?us-ascii?Q?k5TJx13XDBXUrdaRC44CsDqgOvebJ8d1UOvO1O0Jj9J4GQJ4IgS1Y8Cu1SB/?= =?us-ascii?Q?ck9I/WjRdwHHp/nF+sQ8uV1GwY18+CglnOknDnDeOVVK8xHclLrikz/XRxuU?= =?us-ascii?Q?7BjvufF+NtLAmaAtCMuVinZyIr3Pi7BihI2yJI5SDH27jFD2px6lnUQdlF6v?= =?us-ascii?Q?mXP1zDnM9gw+KJa7TYJerMcEoyCUjnpJcS3Qia0ap/BJ2yxh2tZAfjSdGbRu?= =?us-ascii?Q?pn/9e4XSXDOn86WPPMLjWnO/U88J3ddcV0pEjtbs+Sqy3L5/vQdPXGvkWE+W?= =?us-ascii?Q?j+8UdSW/FyqCLGwk5HZoWcuc3SFGAJ+pz/JBcHwglg2x+LKSxH+pqopHyKRI?= =?us-ascii?Q?a5oGcrWZtwQ+wQHsEgR1vWCRcPgC6IkumilLEt/rH+jxWd7+DQKcGGzxuXX4?= =?us-ascii?Q?k6VIIzwm+OaLSbMyz2zlX7QiRHdOWFmgEOowttP1I962BDNWAq8VkbZPVHst?= =?us-ascii?Q?ilLr9sXA4SoGD3JI1iQrXrjuHwubxmULr+9/MQ8EE2Lko022Yz4CdRnmVw/L?= =?us-ascii?Q?Lg=3D=3D?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: D/E/Ckqbo/3m+ZVKbqvEacRcTRROzlq1m6Wsb6bIlg7Galu5ElPO0qpc44xf4BuYB0qNm8IOi4ye1retm6lLUvg15N/qugEB2UWEFa7fQunu/oDaOEAvIAI+LYaxYHRRoDobjz0Amp+nEg+9h1nzoMQauxeIUbMDsdBAgzgik9SQAVGMjVQzM0teLuCXYE4UGCIuq+rf8Bfiy0VDUo1jn+TARaCtS/Jwb8oBPZQQRVsoQ1zOkmKBWDUbGCzuYjqg4BccjdVdFRhiWLHD0ThMT1M46FZQ60hU7EFlywBluzkgdodkv2zUttBMuV6ti+nrADWJObTINIoX30G/KjvVCUi5MQMadZlQ0im+Nnro5v90CuR5FDwxprv9be8/hvK+zbS2MDWZkKFu0Xhayx4fAugaxpV8Sx50D52TV2/dCd+I+rh2lGl7kDfywAefWvMyzch0LoA61Y8gt0+T2V+QgOzU+wXjemgIlTyHRG1nkjV0dhESoN7HEYjhn/bIIzdby+AHTUY/w/WzKOKWJhPtLP39EzZGWnHMZDnwCG0+budSHyVku31QZ/flEWKEb2jVuf4q9dXZWRIElOwNVcIwPxU0nS7CMjtU3bKzZgaG0/3GTEWJX+bJmtwEaC4wVbuqfxlQrr3ZfJPL5VU7Jncve+7OBR2+yIneX7mh6C/Kjf9W1WqsLw4v9VZwhJvposj7NaMek1gTcd4pjgUMph8Bev2+XEP9gx48GkI04WDTLLQ9HFwHoUCgc5C+McCJNFPp64DMfzPsU+SvtyFdv41EUe2EDX7i3JPo8t1i9nsd70nnOWHozXSstA2ZhH5xqH4t X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: e780a539-0353-455e-d49b-08dbc3365f48 X-MS-Exchange-CrossTenant-AuthSource: DS0PR10MB6798.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Oct 2023 10:57:29.9787 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: x6DvAltQ1dAsARO9fw9ie+RM6enfQvrGf5Vr/bIda9VEbefxQ6fitQWPrlL9xeABi4RMKb8D5APuwHI+tCtQYw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR10MB4700 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-10-02_04,2023-10-02_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 malwarescore=0 adultscore=0 suspectscore=0 mlxlogscore=898 bulkscore=0 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2309180000 definitions=main-2310020081 X-Proofpoint-GUID: xqn370vf0tYyq5e7xKLIrpUsPWikb7hs X-Proofpoint-ORIG-GUID: xqn370vf0tYyq5e7xKLIrpUsPWikb7hs X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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 29 Sep 2023, Torbjorn SVENSSON verbalised: > On 2023-09-28 18:41, Nick Alcock wrote: >> Aha! So this is *not* a problem with functions returning int -- it is >> specifically a problem with functions returning *size_t types*. > > So, I'm not sure if were are talking past each other, but I don't think it's a *size_t type* issue either. > > As I see it, there are 3 different scenarios. > > 1. The function returns a signed integral type, then -1 would be fine. > Even a simple (int)-1 would work as it would be sign-extended. Ack. > 2. The function returns an unsigned integral type that is as wide, or > wider, than unsigned long. In this case, CTF_ERR will be zero extended > and the value will be UINT_something_MAX (the number of binary ones > depends on the sizeof(unsigned long)). Ack. This is the problem area, because the interface contract for libctf specifies (or would if it were written down anywhere) that you can test all signed returns for error via < 0 and all unsigned ones (like ctf_id_t) via == CTF_ERR, and CTF_ERR... has a cast in it. I suppose if we changed CTF_ERR to (uintmax_t)-1 this might work for all cases, but a) uintmax_t is an annoying sod that doesn't even extend to the largest possible unsigned integral type on all platforms and b) this just gives us the same problem from the other side if the unsigned type is shorter than uintmax_t (which it almost always would be). What would happen to the (unsigned long)-1 the libctf function returned when it was promoted? Would it turn into (uintmax_t)-1 consistently, given that the type has no sign so sign-extension presumably does not apply? I've tried to figure it out from the standard text and I guess fevers and bacterial infections are not compatible with reading standardese because I haven't worked it out yet :P (or maybe you need to be on more serious drugs than I'm on when reading it. It might well be that way round!) > 3. The function return an unsigned integral type that is narrower than > unsigned long. In this case, the cast to unsigned long is wider than > the return type and may overflow(?). Is it safe to return something > bigger than can be represented in the return type? Are there any of those at all? I don't think so. It's possible in theory but I don't think we use unsigned int anywhere. I suppose size_t might be unsigned int on some platforms, and then this problem might arise. > In my mind, I see it as we need 2 different implementations. One that > returns a simple -1 and another one that casts it for all unsigned > calls, but maybe I'm oversimplifying this. I suppose if it was always done *at the return site* so the compiler could always see the return type properly, it would always get the cast right: my worry is the CTF_ERR at the test site, in the user code we cannot affect (except by changing CTF_ERR). > To make things easier, I would actually consider just having the > assign statement and the return statement inlined (without a macro or > inline function) directly where they are supposed to be. > > Would you be open to removing the ctf_set_errno() function completely > and just expand it to where it's called (almost like my v2 patch, but > everywhere instead)? Well, you could use a macro to make it less gross. All the code duplication makes me wince a bit. But more problematic from my perspective is the implications for the callers. We're trying to get either -1 or (some type)-1 to the callers so they can error-check it in a consistent and not-too-horrifying fashion, after all. (We could add a ctf_is_error() function or macro that does whatever magic is needed if it's too baroque, but that would be my least favourite option because it looks nothing like a conditional.) > Alternatively, we could start the discussion on adopting the C11 standard instead, but I fear that this will be a much longer > discussion than figuring out what the best approach would be for libctf. Agreed, or I'd have proposed it already. Toolchain projects like binutils must be conservative, and there are no doubt lots of archaic weird but valid targets out there where the bootstrap chain requires binutils building before GCC and the system compiler is not C11-capable. >> ... sorry, I'm still flailing at it. Maybe the above is helpful? (It's >> only a very small change atop what you've already done, I think.) > > Let me know how you want to handle this. :) I think we're still narrowing down the problem, really. -1 is such a common error return, it's amazing how hard it is to make it work right :) -- NULL && (void)