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 543173858D1E for ; Tue, 21 May 2024 10:13:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 543173858D1E Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=oracle.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=oracle.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 543173858D1E Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=205.220.165.32 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1716286439; cv=pass; b=raRkWmvbR2tu1LcqQWUz0ULAMzwPpGB4qIX3UWzWpY/Cf7FAtItzBdye2w58966J7IDydlOt4AbSZCnNmKMNAEvIMosTG0+JJJGGgIU7jLnJZ+I3r43PNYj0AuzxXcKv1JJz+FID/+2RcVGhWtZ8yYNyR1V+9uZwWgGa1jxNBRU= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1716286439; c=relaxed/simple; bh=M1JCEJsJ79gObFaGUadd37VHdof5yZR7vbspB1bco5Y=; h=DKIM-Signature:DKIM-Signature:From:To:Subject:Date:Message-ID: MIME-Version; b=Lmv9VQ6R3g+zHh6L4TMbtY6Xy9q7KhjXNQoroFJccONmKY943n8v0ebfjn3F5wBtK+aBs9Qo3F1dp4h9egHko/RrG9gWxkHTZzcZ5MZ71IOk8ipL/41Arnu6LoIvJpFo2spXaJa26xwI4VbrCCttIOddFhaWH5fAvK9SxMUcnro= ARC-Authentication-Results: i=2; server2.sourceware.org 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 44L7xWOn000523 for ; Tue, 21 May 2024 10:13: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-11-20; bh=kg8AIMHzCSIaNugDiray0mGKE4vK6b2BAvjN15MDbz4=; b=GPIDgst0i4R82tcazitbZ4RxtwYlRy012Yc5ZfW6W+fZnW6vH3yA3x+BGS+qV+UqMK3u pvDrLUtwnEhZ1umhq4BJqrjHXvwZ3XtHTN2s1Xh7ayesiHFGYdl4amaPjuAMsQLumvam g79phXa9yrYq6dFST6HvusnK86/K7qpUxD2Cg1iMaA3YpTchsVm2fZwR4iYaysLCyqIZ FCVCUQQq1kmrmukiD9fbtjqsEZyD6G7LaoPmUQkhLtSfhhtm6UvJa9vFt6wkyIl0Poan s+pefPYilf5dqwDkAV1PPN5uPn9Ea2zYRtSvOqw5Aosl/FOEOaFDfralO4Db9jHUoV1L ig== Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta01.appoci.oracle.com [130.35.100.223]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3y6mvv4u68-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 21 May 2024 10:13:54 +0000 Received: from pps.filterd (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 44L9mwDG037886 for ; Tue, 21 May 2024 10:13:53 GMT Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2101.outbound.protection.outlook.com [104.47.55.101]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3y6jsdgrb0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 21 May 2024 10:13:53 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gpBIiCyo5+IqjQ+Ev2Kf+1B20KprYmu9gdn+BeqPJn+LDL1WkWUxMjRnxUUimhfMPXyVn6Mx45z3oQZWVoAMTc63MvjXVXVjGW3V2R0ccvE9K32uGDWqncBn+1pmUXBRyzvt6pfJXsEDUuyYQpKsRNYfQy7yta0Fok+KyLCC8m2ZC7zfVn+FHWJjk56Uy0P8TQSdZgGEeaaYpGGqmpdTMbZtbLe/BcRC+gq4g+2pV06YsV3i1yXS7sk1pG0kDT8o9bJynvMNyzEmy5oShzLExJiNjUWRx7enwlP5FadrEFD8IqpGP1VCorut7PyziVgBCKW1AFzUwCj62rfoxfGbtw== 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=kg8AIMHzCSIaNugDiray0mGKE4vK6b2BAvjN15MDbz4=; b=FBK+k5YnsZmpRIUHAMZElSM73aTPP2rrN7MCumNs2SoT0FoZ4J2P2Ah6Pj52abBWg7yOa4GQUyL3R+2YrSBxrlAY/2+ryRVaGT4+qacWdBcDgbDZNgmziL9b+poFE27RNaEiYEwEj30J7ttu1MENujhPjTdKfL/pIDDWDLItSeh6yLxmUWX+UNZNP0YXKdhAE5GU32v1LipkfOL8ZTf6VbEhwJesmbsaqwWw50co90u7S7ck7dvmXK8uhNJA+Y0pilZaY6jqbgL92J14WIGLK+WkfwZlLPwSGtu26MLG9SzzDm06xC3R2fpLue26uuIHd7o2ZcCk+La4vNr0V01yfg== 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=kg8AIMHzCSIaNugDiray0mGKE4vK6b2BAvjN15MDbz4=; b=Cif9KPJpGrt7GD3PTdIM3p+nuhxaHqdy4EYc94H7obMRmB1wsAqVAPt0uJwYFWW0+Rya9fomzaf2nxt5JKwUmsN7+VGHko2ZmvR+8aA6rbDMTAKmvg5jZfFefnj1PDFhfaYyYO+SDbEtyS8C+edkdHULFvRIezC4h+cZhgniwjQ= Received: from MW4PR10MB6608.namprd10.prod.outlook.com (2603:10b6:303:22e::8) by DS0PR10MB7319.namprd10.prod.outlook.com (2603:10b6:8:fd::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7587.36; Tue, 21 May 2024 10:13:50 +0000 Received: from MW4PR10MB6608.namprd10.prod.outlook.com ([fe80::f9b2:8c8b:841a:aff3]) by MW4PR10MB6608.namprd10.prod.outlook.com ([fe80::f9b2:8c8b:841a:aff3%3]) with mapi id 15.20.7587.035; Tue, 21 May 2024 10:13:50 +0000 From: Nick Alcock To: Stephen Brennan Cc: jose.marchesi@oracle.com, indu.bhagat@oracle.com, binutils@sourceware.org Subject: Re: libctf: new enum-related API functions: request for better names References: <87ttiscisr.fsf@oracle.com> Emacs: (setq software-quality (/ 1 number-of-authors)) Date: Tue, 21 May 2024 11:13:46 +0100 In-Reply-To: <87ttiscisr.fsf@oracle.com> (Stephen Brennan's message of "Mon, 20 May 2024 13:47:16 -0700") Message-ID: <87ikz71nhh.fsf@esperi.org.uk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux) Content-Type: text/plain X-ClientProxiedBy: LO4P123CA0532.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:2c5::14) To MW4PR10MB6608.namprd10.prod.outlook.com (2603:10b6:303:22e::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MW4PR10MB6608:EE_|DS0PR10MB7319:EE_ X-MS-Office365-Filtering-Correlation-Id: de2daa08-dac8-4903-c73a-08dc797eb5f2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230031|376005|1800799015|366007; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?t1yuoMSwb64fOm4BOhu0EbCbA+td/lQPJm9+lqpeQm8x3AhPKKa0Z7a9wAss?= =?us-ascii?Q?qDUnyXc/ZTOOUx3VXAbTGg3hhb3Z9UmteJo24Cf5DCGdHak+G+mO1bwo4IsO?= =?us-ascii?Q?jCfWqE32vK1u+24o7n9KN6v65YGHBn1UjKgY6sub4XE6AeJii4qe1SBUIDPr?= =?us-ascii?Q?/vGkBNsmEj0+VppuE8aC0iY84BjIwV2AvoJYv/i23+E12sTz0Ki1+Vi2ZRDU?= =?us-ascii?Q?Ch2KajHtQZcCixZw5w/Mk9xRuunMqBEExymeYOfJ48hMZ7MV+Bb8EAe9BnsZ?= =?us-ascii?Q?G9LwVAfvB0bnKTPoz8IEN+zFTPK2ATOv8U0fXPYiHDqnj+7puzyc8SRGA9yr?= =?us-ascii?Q?KPLkIfVrzbKCUBxyJ/agvnz9bEVlnjpxhnDPDPbwDTb/FgxFccvwefgc6IX6?= =?us-ascii?Q?0BHMU+g+nQCWjiqtjNz9MqByBYPPVTPRGSzLa0xZmy/8jQ1v9isSeI3Xt0eQ?= =?us-ascii?Q?6KxG52dr818E0XBYKaZDiKP8rPDVCRXxzTFlaau+uAY4FKGhsSwZ1S0bW9QM?= =?us-ascii?Q?6NdvLJvjSyDKyAPJ+g+wGv4OaE3tMa7ZUYrdz3LObnP2TL7PthqTKKg4GVhd?= =?us-ascii?Q?7amUNyOBmzlyEzmBYsK+18Ip1WpVCz6FcdxlrqB4SpPJczvyJjhpL11gmiqf?= =?us-ascii?Q?gO9bLAib/OvFftBB4JSE09pVzSfOSyC4pAwyzyReFNspyo7WCEEUhVzxSGCW?= =?us-ascii?Q?Q/OUvNdqKSmQta1ZyAKZUYw4lr3CgaQPH8MHpvKHD+dnSx2Mu9u9xAaYXn1f?= =?us-ascii?Q?w8U0/eLcnjjMchNocb/CajAgTLlRWqEaion5yzq2NHn+dNRJ6nuPw+Y5Au3j?= =?us-ascii?Q?MKuEMQtaeVp2atIpG4Emus7O9NQGqIvIXDxwymvDBmUHxDCXYxsFWyca6Oyj?= =?us-ascii?Q?riGJq2Lgx3UK85/QtO8xmqZfqrspqPGLRIxPFo4WNgTpbYlmlxhOrwLi1tgc?= =?us-ascii?Q?QPl1y46NqfHPWiX+Nokh9rqsrs/qtX5CgWK34Ax2ZYdfiWNfucFC3ZORET9Q?= =?us-ascii?Q?10SFjosleYtWUfaRKIWeLEoPb1akgQeoI4EfUmtsPQT/fLieroF7xIN2HyBL?= =?us-ascii?Q?zEpaWI5PdFg1/YPxIJpespUfEWD60qpQEnwICWheEkqCJ0tTweTSdTmbCI8I?= =?us-ascii?Q?rKYJFZITSsWjE1eWM1joPhn8ycFgnoUqGP7vhsRpPiy+Nsy69iMuWS3Cemxl?= =?us-ascii?Q?79Ro88G41tYapdiTXR0Q7YEQeSziPWlAQ6AYmsBgQii0MctiJcVa6aP4QMU?= =?us-ascii?Q?=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MW4PR10MB6608.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(376005)(1800799015)(366007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?W7gvnd0cmgsury9YqsojwiweDHNoxfdgKq83Sx+C47jb7/PsUJxVAboeOly8?= =?us-ascii?Q?bm+VtqEdbmyAV5O8NEc4o/s4KZUBxYOZb5ocrQX2F/0/QwSKa5+6RQDcOvIN?= =?us-ascii?Q?Q2pepLKcL50J18udgerxRHXkBquUltX+Zib/3XhkkYlH0s0x2Z2dJfmOYsne?= =?us-ascii?Q?tMsoWKHoqAL2aSULwapkVQYpY26tN1RYt08LUHgu/mcy8NK3llG/i5oEGLD1?= =?us-ascii?Q?gFCUmhRqT5HnkXOTzmq4QBZI9N0QBnbsCVHlVt0G+NcfDNvBW3GC2eWGsIgU?= =?us-ascii?Q?3eQg1NkI/bl1WAqPPlxK5V01XlGUcaZe31oSlz5Csz+TYXqMtSYwqA4+mbld?= =?us-ascii?Q?P3nx+L5NePOG1Kir5jUEPck7AosNaFweuOAZnBL1l2IjBMIjeEZbXoB/QzcK?= =?us-ascii?Q?msfgaA8ygwRbfoy7G/0AVi93EPq5lOV7rop40RRckX4bNOTM7UbObbe/zFGH?= =?us-ascii?Q?ftwVoss3MK1NUrQiQvHkl/zr6J9EUsanH8DEnyv10uUz75Ag0t4WjQRMmUdF?= =?us-ascii?Q?pkIWj8ovKieCeUVn5Q79ecVU6ePh/mTUi+k1uHF2V6MuuCakPySEh1Hs7NV5?= =?us-ascii?Q?L5qdHNb0eV657tlYVtLcoenFQLz/bZn4qhCuqyajlZBm3yfs2pV9XG1EOt3m?= =?us-ascii?Q?MQKOvjMECLL1yB8afNOGWr7l2PUj4+ssvjsRmajDTJUfXTY2KCTG8X0zoFwv?= =?us-ascii?Q?kp4UJL8+NGgn1ZDf5Hl4un1qiSpL853nwbVIbix7Sixln97UPUP3jUEAWvKc?= =?us-ascii?Q?NvA+/+XEBpDB7LbyBboxQSEJIFQIbkPruEsnjpMyhZ45Wvr25nss9vE+txF8?= =?us-ascii?Q?J8nNvtMUGS8sqtNOBQJ6hd0haMkfSKK6bpp8kLLkMx3oslAo23yPx/qzRtuN?= =?us-ascii?Q?Fcl7EH6A3LfxKW3DO+rgaz0Q5ot5YF+vHgFW33kQHr3c01FXpBS7tLlw5aZE?= =?us-ascii?Q?U8nLO+4li0VsLfDfvnXr/BF5nqCjtjMhaF7X19i9Pkl1End4fzkTXsz0qW+y?= =?us-ascii?Q?ZoPx8qQ2NFXdCUItj91zgbSixrhpD4OT9eqQt1nyGD4h2Y0hb631Lvw3LKGl?= =?us-ascii?Q?+CuwdY6ALfagv7Sb/1DGYf1bve1+Ik2mwRjpsMvzhVO7UdCf5mpHZnc+X5xn?= =?us-ascii?Q?Gu9Qi3UhPKmbD/VvFCTjO+6pvmRkcr8falzxx9KDGVmYWNtU/6I7HLkHHkJD?= =?us-ascii?Q?i8JAxMp00I1wNbyNkt8Z1otRBVbnLnk7dTB6opHqwU9LdBggu83bO9G/PeZ4?= =?us-ascii?Q?Ng4AjvTT41/b3Ia5mOkxtu5P3GN4mXDjLc3GsvPxMbMO7XxBv9AjeNxlU998?= =?us-ascii?Q?u1k+TyRkHOyC3ODQu0Y4+xd3GMqh0x0mp70cm8fyIWhDJw1Dd5ps8Z04KRIk?= =?us-ascii?Q?wfJpB1vi5GHdxnqJ8Qk8vSZx36JMj76ac4wcSxPI40XCx3YsAkG1aAAzH/oT?= =?us-ascii?Q?yCb+lVX61etLfAvxyM70k6xwPNgNGMFB9f+aw3NtYpjIYVmZYR3gdlPggh6p?= =?us-ascii?Q?IncrWVZkK1QqzQXjcKKbkh6KyG6VwQ5DQK1xZrhUl8KVjmhWV9aNrayeD7Kl?= =?us-ascii?Q?ZswlbaeyT30nowDE0OpyXfOT1UL0EM/qMN1mkEPeaNZn3Lo6W/44ZmTWks5j?= =?us-ascii?Q?NA=3D=3D?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: kIOTvNfmFohjSkHapMHbxlQLneT4vpLwA8gKDNYlFhMXH43SNvhdaW17I2k7zgKiLELnn0fQ/ye7Clzkxtm/BTcJ6G6U6sJwyBDpTx1xTjgsiT04lva0fwEG3T4d0hZ/zPzvMbC5sVfhhMt6kGczns18WtjeqM1czBDeh46Fo3cMFBW0jpNtFA1kadLRNgrbYqacV8WIv3zgcHuNwt6bXVay4wsPcdDJmII3vv8+9fzF9U1j5wX5LDBSnRl9wcyMF+QcLQlcRhgxAMwtT+Y9NoB6n4gKIRcYFCGrNM8rg2rD1pkrXZ2lceGX3E3EUkSsYNOwwr6A6i0MtzVD9gXW4lI1myR654ghedxIszqwOH9GVH702AK/+Y+VNFMJeEjdXlQG8IQ5iVsj/NgbrlutRD+uPzE05V6qXDBfZL7zC5OilE/pcqNIsZuic8pePk1VRZYrSi3Ua2vKht9DXYldL/wSDxqFAqgaJr7LgkkC+VOJ52yMfNNPQxbCPyhBEppUIdQK9aUoJy4lSlYPCKqYSLtbQDD4FppKQW4bIKR1MiBShXa3q67fuwxG0/WZjVCS5xuJt7WelSuXwPB3Mv9u2IQhVgYud3aD0CpBcjAgrew= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: de2daa08-dac8-4903-c73a-08dc797eb5f2 X-MS-Exchange-CrossTenant-AuthSource: MW4PR10MB6608.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 May 2024 10:13:50.7615 (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: o9B8om4Kppw7lthHWlKmmH+jK7mUfUIOOTs+K4Hhmb2BPtz9VU1xL/EtEbRVlPYBEIIkajfn4r1kvdvbdIXxuA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR10MB7319 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.650,FMLib:17.12.28.16 definitions=2024-05-21_06,2024-05-21_01,2024-05-17_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 adultscore=0 mlxlogscore=999 bulkscore=0 spamscore=0 malwarescore=0 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2405010000 definitions=main-2405210077 X-Proofpoint-ORIG-GUID: FPIWpvBFwSGlooLWZgXiCa2sdcz95Exb X-Proofpoint-GUID: FPIWpvBFwSGlooLWZgXiCa2sdcz95Exb X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H4,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: [Jose, Indu: your only interest here might be my musing about identifying what mysterious values in memory dumps are: search for "#define". If this were to happen it wouldn't be soon, would definitely not be on by default, but it would need compiler help to do something much like -g3 does now.] On 20 May 2024, Stephen Brennan spake thusly: > Hi Nick, > > I'm not subscribed here but found the mailto: link with In-Reply-To > header set on the archive page; hopefully this reply works as expected. It does! I like your suggested API and am switching straight to that instead. It's such a good API that my eye skipped over one function and I thought 'oh, we're missing that' and proposed a new one with the exact same name and parameters in the same order before noticing it was already in your list. :) > Nick Alcock writes: >> So Stephen Brennan pointed out many years ago that libctf's handling of >> enumeration constants is needlessly unhelpful: it treats them as if they >> are scoped within a given enum: you can only query from constant name -> >> value and back within a given enum's scope, so if you don't already know >> what enum something is part of you have to walk over every enum in the >> dict hunting for it. >> >> Worse yet, we do not consider enum constants with clashing values to be >> a sign of a type conflict, so can easily end up with multiple distinct >> enums containing enumeration constants with the *same name* appearing >> in the shared dict. This definitely violates the principle of least >> surprise and the (largely unstated) assumption that the shared dict >> should be "as if" the entire C program's non-conflicting types were >> declared in a single giant file which was compiled with -gctf: you can't >> write a C file that declares the same enumeration constant twice! >> >> Half of this is easy to fix: libctf, and in particular the deduplicator, >> should track enumeration constant names just like it does all other >> identifiers, and push enums with clashing names into child dicts. (This >> might eat a lot of space when the enums have many other enumerators, but >> most of that space is identical strings, which means we can win nearly >> all the space back in v4 via the string-saving trick that is the second >> entry in .) >> >> But I'm having trouble figuring out names for the new API functions >> we'll need for the rest. Right now libctf has these: >> >> /* Convert the specified value to the corresponding enum tag name, if a >> matching name can be found. Otherwise NULL is returned. */ >> >> const char *ctf_enum_name (ctf_dict_t *fp, ctf_id_t type, int value); >> >> /* Convert the specified enum tag name to the corresponding value, if a >> matching name can be found. Otherwise CTF_ERR is returned. */ >> >> int ctf_enum_value (ctf_dict_t *fp, ctf_id_t type, const char *name, >> int *valp); >> >> /* Iterate over the members of an ENUM. We pass the string name and >> associated integer value of each enum element to the specified callback >> function. */ >> >> int ctf_enum_iter (ctf_dict_t *fp, ctf_id_t type, ctf_enum_f *func, void *arg); >> >> /* Iterate over the members of an enum TYPE, returning each enumerand's NAME or >> NULL at end of iteration or error, and optionally passing back the >> enumerand's integer VALue. */ >> >> const char *ctf_enum_next (ctf_dict_t *fp, ctf_id_t type, ctf_next_t **it, >> int *val); >> >> At the very least we want something like dict-wide equivalents of the >> first two: but ctf_enum_name has the very annoying behaviour of just >> picking the first name if there are multiple conflicting ones with the >> same value, and on a dict-wide basis there will be huge numbers of these >> (can you imagine how many enumeration constants have the value 1? :) ) > > I've never personally had a use-case for ctf_enum_name(), looking up an > enumerator by the integer value. However, I can understand why you might > want to do it if you know the type ID already (e.g. a debugger may want > to represent an enum variable with the symbolic name). I mostly put it there for completeness -- it's something you can't do without a global view of the type system, which you *can* do with one. > But I can't imagine a case where: > > a. I have an integer value, and I know it's an enum, but > b. I don't know which enum type it belongs to, and yet Indeed -- this alone suggests you have no idea what it's being passed to, so where did you get it from? Usually in my case this is "memory dumps but I'm not quite sure what type it is" and I want to know if some huge mysterious magic number is actually an enum -- but for this to be really useful we also need to translate #defines of integers into something enum-like (a single big "enum" named "#DEFINE" perhaps, or some other C-invalid name). Hmmmm... > c. I *do* know which CTF dictionary it belongs to... > d. And I want to get the list of all possible enumerators it could be ... but this is a good point. Sounds like a cross-archive one would be more useful, but still not very useful :) I'll drop it for now. > Maybe I'm deficient in imagination. I'm sure this use case could come > up, but is it something that libctf really ought to optimize for? I'd > argue that there are only two use cases that really ought to be > supported at the dict-wide level: > > 1. Lookup an enumerator by name. This is something that users of C do > constantly, implicitly, just by using the constant name in their source > code. So libctf really ought to support it efficiently with some sort of > string index. (IMO, it should be supported at the dict and archive > level). And this is something we need to track *anyway* to prevent people adding the same enumerator identifier repeatedly (in a given dict), you know like they can now without libctf complaining at all, even though it's totally impossible in C. We probably do need to provide an archive-wide iterator version of this as well, so we can look up all enumerators with a given name -- and that would also handle the unfortunate existing case of multiple identifiers with different values, coming from different enums, in the same dict. Like the one you propose below! > 2. Iterate over all enumerators. This one is already supported quite > well in with libctf today: ... of course this too only works on a per-dict level, but that's probably what you're after, since usually you're looking at things from the perspective of a particular child dict. > You could introduce an API to eliminate some of the boilerplate, which > could be nice enough. As an existing user, I probably wouldn't take > advantage of the new function, since I need to support older libctf > versions. For now :) > function. However, a new API for this would be much less flexible... The > above function allows me to run code for each enum type, before and > after handling all of the enumerators for that type. A > ctf_enumerator_next() function cannot really give me that information. [...] I think it could if properly defined, though the definition would be a bit odd. Something like: /* Iterate over the members of an enum TYPE, returning each enumerand's NAME or NULL at end of iteration or error, and optionally passing back the enumerand's integer VALue. On end of iteration, sets ECTF_NEXT_END. At end of each enum, sets ECTF_NEXT_ENUM_END (and iteration continues). */ const char *ctf_enumerator_next (ctf_dict_t *fp, ctf_next_t **it, ctf_id_t *enum, int *val); With that in place, you can do this: const char *enumrator; ctf_id_t enum_id; int64_t value; while ((enumerator = ctf_enumerator_next (dict, &next, &enum_id, &value)) != NULL || ctf_errno (dict) == ECTF_NEXT_ENUM_END) { { if (ctf_errno (dict) == ECTF_NEXT_ENUM_END) { /* end-of-this-enum-type stuff */ continue; } /* one-enumerand stuff... */ } if (ctf_errno (dict) != ECTF_NEXT_END) { ctf_next_destroy (next); /* oops, error... */ } Now possibly this is too different from the way other iterators work, I'm not sure... the repetition of ECTF_NEXT_ENUM_END is ugly but there is probably a less ugly way if I just thought for a moment :) Compared to your example, hm, I'm not sure if this new API would buy us enough to be worth it, but it's at least *possible* to do the same thing looks pretty similar, and means you don't need to filter out non-enums: > ctf_next_t *next = NULL, *enum_next; > ctf_id_t id; > int isroot, enum_value; > const char *enum_name; > while ((id = ctf_type_next(dict, &next, &isroot, 1)) != CTF_ERR) { > if (ctf_type_kind(dict, id) != CTF_K_ENUM) > continue; > enum_next = NULL; > while ((enum_name = ctf_enum_next(dict, id, &enum_next, &enum_value))) { > /* do something with (dict, id, enum_name, enum_value, isroot) */ > } > } Maybe I'm just overdesigning again. I'm not proposing adding this one yet, not until you tell me it might be useful. > I'd argue it would be better to let users manually do their own > iteration. Especially since they could combine all their iteration needs > into a single ctf_type_next() loop. True! >> I'm very unsatisfied with the naming: to me, ctf_enumerator_* does not >> read "like ctf_enum_* but dict-wide": but ctf_dict_enum_* feels wrong >> too, as if it were dealing with enums *of* dicts. Suggestions? > > Given my (maybe not so humble) opinion above, I think that naming can > become a bit clearer if you don't try to handle so many use cases. To I knew my problem here was wild overdesign, but I wasn't sure what direction I was overdesigning :) this is very valuable feedback, thank you. > me, this is a clear case of a "lookup". The word "lookup" to me implies > a wide search, not simply within a single enum type. And if you only > support name lookup, then the functions can be called: Good point. > ctf_id_t ctf_lookup_enumerator(ctf_dict_t *, const char *, int64_t *enum_value); > ctf_id_t ctf_lookup_enumerator_next(ctf_dict_t *, const char *, > int64_t *enum_value, ctf_next_t **next); > > This would also make it easier to perform the (in my opinion, equally > important) archive-level lookup: > > ctf_id_t ctf_arc_lookup_enumerator_next(ctf_archive_t *, const char *, > int64_t *enum_value, ctf_dict_t **dict, > ctf_next_t **next); Very nice! I hereby ditch my design and switch to these, with one slight rearrangement of parameters to satisfy the not-terribly-well-documented parameter ordering rule for _next iterators ("dict, query, iterator, out"): ctf_id_t ctf_lookup_enumerator_next(ctf_dict_t *, const char *, ctf_next_t **next, int64_t *enum_value); ctf_id_t ctf_arc_lookup_enumerator_next(ctf_archive_t *, const char *, ctf_next_t **next, int64_t *enum_value, ctf_dict_t **dict); (but do we want to return the *enum type*, or the value? I guess the type, as you do above, because you can do more with it.) ctf_lookup_enumerator has an annoying naming difference from the one-enum-type existing version, ctf_enum_value, but so be it. It's too common an operation to force people to use iterators every time. One question remains about ctf_lookup_enumerator: if it finds more than one enumerator with that name (i.e. an old dict, before the deduplicator considered such things conflicts), should we error or just pick one to return? I'm wavering towards erroring with ECTF_DUPLICATE so the caller can switch to using the iterator (or just choose not to, since such cases are rare even now and will get rarer). > The reason this feels so important for me is that, from a debugger's > perspective, we don't frequently know which dictionary to search. Yes indeed. I want to provide better "find an appropriate dict holding this conflicting THING" functions, but I was holding off doing that until after v4 and until I could think up a way to let the caller impose an ordering over dicts -- in every case I know of so far the caller knows that some child dicts, if they exist, should take priority over others if the THING is found in them, so a function doing the search in an arbitrary order would be useless. > Frequently a user is just saying "give me the constant FOO", with no > scope or anything to give a hint. Looking up a constant at the dict > level is good enough for the 95% of the time when the constant lives in > the parent dict. But in the remaining 5% it really stinks that you would > need to go through each dict and re-do the search (which would likely > repeat the failed search in the parent dict). Hell yes. > => Note: with these archive-level lookups, though, it would be really > nice to avoid returning a brand new ctf_dict_t *. I don't know how the > semantics would work: only search dictionaries that already have an > open handle? Reference count the dictionaries and simply return the > same one if it's already open? This is already handled :) dicts are alrady refcounted (which is where the huge memory leak you spotted a while back came from...). We cache the dicts internally to the ctf_archive_t, so you can act as if they're new dicts, close them when you're done, and not pay any of the opening costs except for the first time. All this is done for you for all dicts returned from ctf_archive_next, so everything that uses that to walk over dicts will get automatic caching. See ctf-archive.c:ctf_dict_open_cached. > If you do stick with your proposed API, which is good too, then I Nah, yours is much better! I was just seduced by the previously impossible operation of looking up enumerator constants given values :) but as noted it's also a pretty useless operation most of the time, so we can put it off until we actually have a use for it (and a better interface, and a way to turn #defines into something similar). > Hopefully something in my ramblings above proves helpful! Absolutely!