From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by sourceware.org (Postfix) with ESMTPS id A2E783858419 for ; Tue, 3 Oct 2023 20:54:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A2E783858419 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 (m0246617.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 393I55jE006253; Tue, 3 Oct 2023 20:53:55 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=aiOl918IZ8++Y0/mAZd5qHx+lzV+s52J870vrqvwuso=; b=PjJqb9x1BlZDhfYGQ9W75DQVEqyfNtG8o06/4e2nMkCVzbviycetttiCsUXJ4fg15IHU ObZzuWoV/HUOI/g0TtrOsT99VlSm0jyv7+afAM/2SGXhtIE4iylIzAQWp21qaM+G5kS8 hhkNU+gZkuXNp/V8FrSa8/ZASLWYMtJe86DxaTjmD0CF12Qw3rOMmkm4HJuaWhFWNodV spoqqxxyLt8Qd2TPSdcF46JOMeCzDSxkKbo1U2KDBLDfIBQb5ofnXxTbMwsOT9yjOony Fap5Y5Bw7whcbBsum5kEQzg/shtTWN5DK8aP8DlCsn0IO1H5cL4GsnUg1sIWBgw+xqGW 7g== Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3tec7vdnxk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 03 Oct 2023 20:53:55 +0000 Received: from pps.filterd (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 393JoDKw002869; Tue, 3 Oct 2023 20:53:54 GMT Received: from nam04-bn8-obe.outbound.protection.outlook.com (mail-bn8nam04lp2046.outbound.protection.outlook.com [104.47.74.46]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3tea46ky3p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 03 Oct 2023 20:53:53 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b5swnd2fUUd+Czkc0Ob0ZuGvbkoH+HwIUBYuEUnxX+XWPEnvCJwolPi1CaovdqB4Xuaebb7UhUWv4tzdM3zEaJ5ymLQ1rYRbGKcDIH9Kf1YXBMy9nye3XBn2+nO+YhmRoxUADqDioCb7/JNserMkRftyqypDrOZ2BSXe2ERduT1wkzhmesoxU8CwwrU14SzAIimGzexvNGnFw5hYJGY8w6o95OdF++gh6HXtHAKInqe2P6/VGnzYCKURh1lgu91BMuTcCJP4NohTHocA10/kRaHk+aHhpMk7TyDaJceDqxxquXxqR0uEHWxB/7ykWpsufSOKoXySDlgxuA7heFDWRw== 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=aiOl918IZ8++Y0/mAZd5qHx+lzV+s52J870vrqvwuso=; b=mNw24QuNK1AT3jBTufxH5ly9lMkz4cOXNhg1UO3c06ufejDRW2OXyjyofXhesRLgc0pvCJMqAIUh9fc9MeobMOj/81E2yZSuu2amE9kai6X0iZgDJ5h1vpzduHxeU5ZocwkE31sUJ9JlA8EFUahNWh8HzpSVHAK6i31hNoZryOVIhfjUJHhsBqJNSXfLHcLf1a9RpGrFurR7kenzx9V+rI+qsxMgRAmXNG2BfJ4jbsiyez3Fcee90kJYM2n9w3hV9aDjZj492b2MKuxj1IrAm3GPq1AN/ye4/jV0rxAxn8VUER9xOXTVawDPFpNSU82YBKMpBG9cvonh62UqYzVikA== 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=aiOl918IZ8++Y0/mAZd5qHx+lzV+s52J870vrqvwuso=; b=HrZH7EYIfocLpAYyVF4m3/Uj70c74wxPP369uBytXmMWGLLeWuovdJBhR05xgX+CKqN4MWen3g7/1dpvn/NpTR8Xw3K6yxt2PrF6VA2tUAVourRbS9yAyNqkUMXeiyyY+eF7Mll6mD9TVrjuRep2VsVa9t8ivE0EvcVCDk1YSOQ= Received: from DS0PR10MB6798.namprd10.prod.outlook.com (2603:10b6:8:13c::20) by CH3PR10MB7631.namprd10.prod.outlook.com (2603:10b6:610:180::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6813.25; Tue, 3 Oct 2023 20:53:52 +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; Tue, 3 Oct 2023 20:53:52 +0000 From: Nick Alcock To: Torbjorn SVENSSON Cc: , Alan Modra , 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> <87ttr9l2b1.fsf@esperi.org.uk> Emacs: ... it's not just a way of life, it's a text editor! Date: Tue, 03 Oct 2023 21:53:44 +0100 In-Reply-To: (Torbjorn SVENSSON's message of "Tue, 3 Oct 2023 14:59:57 +0200") Message-ID: <87jzs3l95z.fsf@esperi.org.uk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux) Content-Type: text/plain X-ClientProxiedBy: LO2P265CA0427.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a0::31) To DS0PR10MB6798.namprd10.prod.outlook.com (2603:10b6:8:13c::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR10MB6798:EE_|CH3PR10MB7631:EE_ X-MS-Office365-Filtering-Correlation-Id: e477468e-01dc-40d4-74c7-08dbc452d985 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ZSBXqv0nEiit+RgYKNpV9xuGu52ycn5rwVvGoBQU2vOiB47+VIRG/44UIgy2upkzGFKR+c+gD+Aqysbr6RXJY0T+FNcQlctJaH1V8L1w+7qHD210vUWJCgR3EMv3sic+oO28IZDgvaJVIHw043yYXcIeJM/ukbwezL0liZlAiLO/iEyjONcnyiVB7PDD4VYrgbZIeURZR90Mkq3/Ypt+jmXK33kWdBh4QHpAIhLbdzYal2H/8hoYxchokWwVSWNdXU9zXxim7i7nh8dieiiL9CFsOtgQbVPJzFWc6ZRnDPiOxyWbZba9lkHtxfqQAT9xTgq1Pcdps282AjqmGPGbzmlxLuMXORFflNzYjn0f8JzN4Y50nLw08IrU8LRi11dKX121Fw2MbrO5hvomPLwMtkVVvy/8eMNWZZ7Af0ntwKPPlrU7DgCK/88IhRFFZMtrnkcJw7grzSk5PeJn7npAHqvqmG4R/eh7+xQicuvjtJRYij2LoU1X0mGFwyIeSpzWS1Q21HAKjHoQTKIdHrN7bRoSQIcsyUbmI4LY+Mbe8zNBLxW3roeJ4FEDHCm6dQdI 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)(346002)(376002)(136003)(366004)(39860400002)(396003)(230922051799003)(451199024)(64100799003)(1800799009)(186009)(8676002)(83380400001)(44832011)(66476007)(6916009)(4326008)(66946007)(6666004)(66556008)(478600001)(41300700001)(86362001)(316002)(8936002)(2906002)(38100700002)(6486002)(5660300002)(54906003)(9686003)(6512007)(6506007)(53546011)(36756003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?i/PDVGOpQ3n1vqWc3qOJ+2D5J+VUshrlyhyUQQuVL8NtkPAx+ei7VvX5EJO5?= =?us-ascii?Q?BJ3ud0Bz2bh17SIwnaJKuOvHFqGCyNo77yd/ly5tKSBRQQPGrN3GGLzGcF5n?= =?us-ascii?Q?Wjw5iMCFKcvkOzoEnuIBCItw42SziWGwYySEgEx5mjyNzGJivpzNLmVxVO5N?= =?us-ascii?Q?08zHqi2eDkMFPJlhJkv/SdnnWLuAks3Oyow4AcIXuxxL1B9hfVjilAyaJX5M?= =?us-ascii?Q?svSk2ZmxmOA3E0+bxNfGcrjCy4SokUvtCUH2uebP0RYv5Axo2Ftlvo/dziHm?= =?us-ascii?Q?YinBTgzHNnv6N7DtutIXb/xoT+Rw5AKDZ4qVyEzJ7cNnJaTT6iUCqzBF1/EN?= =?us-ascii?Q?zDNySxr8sDmBl45DfQ6KzL/TjgHzFKU7TutpjRzQxFTZnxxA10rIDAiBlhT0?= =?us-ascii?Q?NEL2kP8paKFoZV+lHnJuCFTqO/Bpf4u/qOLr6d3lFboP3F6WI6KrmDeYrmBU?= =?us-ascii?Q?P+GgWkOTfvcxufCiC43eH37NP52iMcOHgjTxFRZp2aAh1bmzTFYdtsyotTs4?= =?us-ascii?Q?Lm47kC9oIku013Fd5oYieItL6ZBdyZybwcgxhyZTQk5EqSQa1qfDYuXEsrYx?= =?us-ascii?Q?Q0AVLmG/ENWkoLroNpz++pMzCArvwwJJPHXkRM12pG5Y25JsFNKYolUf+nyI?= =?us-ascii?Q?4xjosWMIcSZnMX1YgTl8ycJK8Q2pWmpbSy49+xIU0Mw4TZ4PLLYnlNmTqWSy?= =?us-ascii?Q?2QSosIEDOT2swbSxbjAAa1NF6YIWpHE3O6/whMZlurpt2YHICgxfAL7pc6kT?= =?us-ascii?Q?4FSROZUieBUiFYRRRRKU0F80CFEmizB2BFAs3q4Y2PoVuqegqe1mV5L1haB7?= =?us-ascii?Q?KsMtaJuxzgtrfQ8KZ6e1xYQKfUDE8p4vFISmpKdOfIpf6qyw+23lgFjOrIXL?= =?us-ascii?Q?ov6bM6w8Kf+eg8bEzNm9SPmdXgQFuZRbtEUnPyyO2/G5Mcdg2N5fDMljTTxA?= =?us-ascii?Q?5RR49pBoGVgEfLeDW/a0zeWU6cFcphKAhf9R4StPvdi927Or97dYgHUcsh6Q?= =?us-ascii?Q?nE9wwGf8jvgtoAV9R/+xqCAcj841SsP4LDHLpGJU+RUtvyAX3dNw1FIfpi/F?= =?us-ascii?Q?/K+0+cN1q8Rs1gf6z9N8KCYVPr6fmdQ6GILL8MPC8cSoczE6Qry75v/rUmxl?= =?us-ascii?Q?roo72ms0NnuM3TXoUGqkD+L4eJ9/L8HvsWdNuNvjS/vTZoXJwDI1RU9kIWWE?= =?us-ascii?Q?SqLdZ+plcaNA9pqbf9Xoiu2IdiKNwuvGw2yDZ4Qofm9YeETDPjxkVW1Ln//D?= =?us-ascii?Q?+uEQyiSCwCrEuaN72a2roTe1NLr1UyqtOW4R/LbWkQcA97KA61u6SWNudXCL?= =?us-ascii?Q?ycq52g7Kw9yqmzM+MzGSuN1uqcvomK4FEXpzSACQOLexczME+8b1f+RjHIiK?= =?us-ascii?Q?/wPlurZ7I76SJdRPSPu3/v+7moTCS0rOcuPhU6dV4hpggDji4yN2uxZk0Eyk?= =?us-ascii?Q?OZHkHkkRQzwEz7YQQl3wRtzJTQKdV+ZlprKnfd4+uwkqhA9xbHdlH7tYbap2?= =?us-ascii?Q?A73mBu31PFobpICdJqbiTbMPWw9gt57FsZxkASC2ObjOOGEX8xZEQg6bb2O3?= =?us-ascii?Q?4hnEEE2GQM+ctWfwx9kB7vkpVLdkKjMtoaGHz30xCbVRt+9tBfAlyBgEs9SF?= =?us-ascii?Q?CQ=3D=3D?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: Q+SzDhHvX2EQe8C6Lpg43X28mCcZIjZgvXbzlZMtwnhQQJJm1XH9KtisGK1SrCmgHxxs1OYPJnuQLje/XWWNB/BsHY01QcCq52b+3+ycTaoXmA/y6cgPjxpK1pvM/V4NUO19XIlMwZc4OKkc0Q0BoSPpCQzpvOD63p+fvuYY43x6NrNJeMktuWxOmbwcI7EPXeFw2XBesHVYQBI+WtZQa93IzT+vhoCbPxBz6KeG5D6LIySbhEcZ2Wv9raB/qJSUsy7eI9AbtyNOSAP9A42bA7pMG5p7HQwxbWVvqWVGG2uvd/yk7t6ItUK3le7u62niQ84coCorDBcmHDl5L203QJN6j54FCdSG8SjcAeY1JxrLRztMvVELesqix/lXZERPF8jkFsBiXKCIZPYRWgeTQCpnzc8Gih/E9NelXOvcFR3Y9wT55fuL4tGoEYnFMs/zHuHmPx4BoRifHs3yyrow+dZCw6WwxdZqRi3PZSonbGcxXIxWupzlF8tn3QWnWIGYCBjLQO6Ip55inQtk4DvsM6TqiKF7Yn2ICtvBmk7PZX5OTm3GboAlOIEJX1QNQ1/Cxe7ZWPq9IsbLUMGXvSIFWXDXmYlm0YHXJvvHFXsHvU3NSqJ38oiuwRvF25uh8Htqd5HE5oryZnCyfFea/LlGkZoPrurJ+dtYchtEXsOp6DqWIM5DItTOYvHajmDMsY+F6q5gQLuyuc/pNqZY6QRiB6cbWzhOE5MvFll0im4teykhUDs4BoGjzCsfe/oclI/rtUkMOgl7vKO1n0DCAdHD/IMA8AAqZd01+c2vTNnIf35p+r8VwGpxiw1m4rFUGcTl X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: e477468e-01dc-40d4-74c7-08dbc452d985 X-MS-Exchange-CrossTenant-AuthSource: DS0PR10MB6798.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Oct 2023 20:53:52.1707 (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: cFhgGQ8DU2uaqoqwVw39ToXdcZkjZW+UHLJJhNUvxDDxuHiba0oLg1+EUPORlPgD/tS5xmg9omwh//og+cYuYg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR10MB7631 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-03_18,2023-10-02_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxlogscore=999 mlxscore=0 spamscore=0 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2309180000 definitions=main-2310030158 X-Proofpoint-ORIG-GUID: cCb0OUwSrc7yKalW73-HuvElxkLi71nT X-Proofpoint-GUID: cCb0OUwSrc7yKalW73-HuvElxkLi71nT 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: This is a really fiddly horror show, isn't it... On 3 Oct 2023, Torbjorn SVENSSON outgrape: > On 2023-10-02 12:57, Nick Alcock wrote: >> On 29 Sep 2023, Torbjorn SVENSSON verbalised: >> >>> On 2023-09-28 18:41, Nick Alcock wrote: >> 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 don't think this is true with the current logic in place. > On a signed integral function, it could be either -1 (negative one) or, if the data type of the called function is wide enough, > CTF_ERR. Oh. That needs fixing then -- there's no other way for the caller to tell what to test, and honestly even '-1 for signed, CTF_ERR for unsigned and ctf_id_t, == NULL for pointers' is complex enough that it's a source of errors all on its own :( >>> 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). > > I suppose so, but does it really matter when we cannot do this part? I was assuming that a *macro* #define ctf_set_errno(fp, err) do { (fp)->ctf_errno = (err); return -1; } while (0); would return the right thing automatically -- but oh ugh that's a behaviour change, ctf_set_errno does not do a return currently. That won't work. Fixing that to get a ctf_set_errno macro to return a suitable value requires the statement-expression extension which of course we cannot rely on being present in binutils :( so a ctf_set_errno macro is untenable. Dammit. > Or are you thinking about just having the ctf_set_errno function > always return -1 (negative one) and let the caller do the automagic > conversion? I was assuming that the callee would do it. > If so, I think the idiom with return_value == CTF_ERR is > going to fail. Oh wait, I see -- if some return types are wider than unsigned long, CTF_ERR is not going to equal -1 for comparisons against that type. Ew. And of course what that type is is platform-dependent. Maybe we *can* get away with using uintmax_t in the definition of 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. > > How would a macro work for this? Not sure. I'm casting about and not even writing enough test cases I'm afraid. :( I disproved the macro in this reply anyway (see above). Sorry, I'm thinking very slowly right now. > Consider that a function returns a char*, in this case, neither CTF_ERR, nor -1 should be returned, but instead NULL. Using a macro > would make this problematic to differentiate. Ah yes, pointers are the third case. Obviously NULL == error for those. > A possibility could be to have a macro like: > > #define CTF_SET_ERRNO(fp,err) do { fp->ctf_errno = err; } while(0) > > but what's the point? > Is it better to write: > > if (some_failure_condition) > { > CTF_SET_ERRNO(fp, ENOMEM); > return -1; // or CTF_ERR, NULL, ..., depending on the function > } > > instead of: > > if (some_failure_condition) > { > fp->ctf_errno = ENOMEM; > return -1; // or CTF_ERR, NULL, ..., depending on the function > } I'd say stick with the fp->ctf_errno assignment, it's far clearer than a SHOUTY MACRO that just does an assignment. The whole point of ctf_set_errno() in the first place was to avoid the need for multiple statements and thus a new block: if we need multiple statements anyway because of return-type pain like this, we might as well dump the macro. (assuming this works, because that's a lot of changes to stick you with.) >> 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.) > > Adding a ctf_is_error()-function would be one way to go, but it would be an API change while all the others I've been talking about > is internal into the library without actually touching the interface. That's exactly my objection too (also, it's clunky as hell). I really do want to avoid that. My big fear here is that you've found some fundamental problem with a -1 signed, CTF_ERR unsigned return (we can't even change the definition of CTF_ERR, because it's baked into callers, while libctf can change under them.) >> 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 :) > > So, based on all we have talk about so for, I'm leaning towards just > having the 2 statements in all places where an error should be > returned and have the change contained inside the library rather than > making external changes required. I think you're right. > Then the question is, would the CTF_SET_ERRNO macro have anything to > add? I.e. should we have it even if it's just setting the field or > should we set the field directly? Regardless, the return statement > needs to be kept outside that block. I'd go for dumping CTF_SET_ERRNO: just switch to a scheme where we set fp->ctf_errno and do a return. It adds a few more {} blocks but that's unavoidable in the absence of statement expressions. (And half the places we care about don't need new blocks anyway.) > Please let me know what you think so that we can progress on this topic. > I'm currently blocked by this point for the tool chain that I'm supposed to deliver. Oh I'm sorry! -- NULL && (void)