From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on2074.outbound.protection.outlook.com [40.107.7.74]) by sourceware.org (Postfix) with ESMTPS id 9AA4C3858426 for ; Wed, 4 Jan 2023 19:42:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9AA4C3858426 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FcCeyGpYWYFkaC8Q2uIraQ1kzWtLGSkozNrisJtQOTU=; b=EyjShMTsf1A2g+ykyXr5/HASE1uNdBJhx0733ulor3GY4uQd6TKVzo/Xy+H++eaC5oEpQu3wvZtJYoB3HukrZszAm2FlPXSqmVyYzp2+qQONHwArPYnOhnZkzzRNNNknuUwi72TybPgiRenE/QRXIWQMVaN1QSOk0yuVroRtgZo= Received: from DUZPR01CA0048.eurprd01.prod.exchangelabs.com (2603:10a6:10:469::17) by GV2PR08MB9256.eurprd08.prod.outlook.com (2603:10a6:150:e3::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5986.7; Wed, 4 Jan 2023 19:41:45 +0000 Received: from DBAEUR03FT057.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:469:cafe::db) by DUZPR01CA0048.outlook.office365.com (2603:10a6:10:469::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5966.19 via Frontend Transport; Wed, 4 Jan 2023 19:41:44 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DBAEUR03FT057.mail.protection.outlook.com (100.127.142.182) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5966.18 via Frontend Transport; Wed, 4 Jan 2023 19:41:44 +0000 Received: ("Tessian outbound 6e565e48ed4a:v132"); Wed, 04 Jan 2023 19:41:44 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: b960750ad89a3a5c X-CR-MTA-TID: 64aa7808 Received: from 47c57be1f30e.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 805986B2-D865-4C80-A517-5A709C6CA192.1; Wed, 04 Jan 2023 19:41:36 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 47c57be1f30e.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 04 Jan 2023 19:41:36 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=f6+l3KWiLBRTerRyzEPqFvyGCxKLTHHca9I38714ynvtcKrUjr4qkcDiyN0LPSReOCPK7Yh+ftqm6qU1iSvTYk6JUPyz3m5EuWxMHSmaibC3upsKTazBvzVfv1uaCnVzrC53kelYE/gkidgpEf6gsYyKgkA2vJ5Zxo2+D6qrawbjNuUJwzbCskSvgJ7/SCNxAsFwq2Ohaq7CBB0iXtGgrpmynqEhDcfT5eqJztpfZ5sgIkScTFMUCIdDj8zRp1Ph+RfksSTAvcJF7r4n4ynxkTF3QF/BxB6CY9vOiGry8tITSFqe21VB9D+zWjNrLoCiOQcV4vcSdjnFMXPu4Md+hQ== 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=FcCeyGpYWYFkaC8Q2uIraQ1kzWtLGSkozNrisJtQOTU=; b=kYle3m8FDIrVm33ZJjnmvnRWacoFaHFbBioaPf6UZN5n9DBdF2XUeQY1a3aOchu6JvakwfX+wEhJwJ3LC1CTdJKnYBevd0NJ5U2jkn4cycbs7hNcZ8ex0TDRT7aQptLpl1S/QQVythl2EuA5cQ2Lqyj5Cnmw5Peo/dhtJAm8LbyfqqvgAqCBsXFjzoRIf7Jh1/sVBCNx4m8j3GJqW8X0IO46rol7Hvnd4pVjyeDRjayIvr3OIH+AEjLnWe6q9CA80MDFFRCimZhwHef9z8XH3haOqVV+jdcw0GVIz8TPo8Sd3cxJD1Q4QsYI8CoT8isM2JOPJNhZxXmxzs3KWgf4Lg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FcCeyGpYWYFkaC8Q2uIraQ1kzWtLGSkozNrisJtQOTU=; b=EyjShMTsf1A2g+ykyXr5/HASE1uNdBJhx0733ulor3GY4uQd6TKVzo/Xy+H++eaC5oEpQu3wvZtJYoB3HukrZszAm2FlPXSqmVyYzp2+qQONHwArPYnOhnZkzzRNNNknuUwi72TybPgiRenE/QRXIWQMVaN1QSOk0yuVroRtgZo= Received: from PAWPR08MB8982.eurprd08.prod.outlook.com (2603:10a6:102:33f::20) by AM8PR08MB6449.eurprd08.prod.outlook.com (2603:10a6:20b:364::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5986.14; Wed, 4 Jan 2023 19:41:30 +0000 Received: from PAWPR08MB8982.eurprd08.prod.outlook.com ([fe80::66e4:4940:d096:4f7]) by PAWPR08MB8982.eurprd08.prod.outlook.com ([fe80::66e4:4940:d096:4f7%9]) with mapi id 15.20.5986.014; Wed, 4 Jan 2023 19:41:30 +0000 From: Wilco Dijkstra To: Alejandro Colomar CC: 'GNU C Library' , =?iso-8859-1?Q?Cristian_Rodr=EDguez?= , Damian McGuckin , "G. Branden Robinson" , Alexis Subject: Re: [manual]: rawmemchr(3) and UB Thread-Topic: [manual]: rawmemchr(3) and UB Thread-Index: AQHZIGOmtuYfIbHwl0OIELEhaPbTmA== Date: Wed, 4 Jan 2023 19:41:30 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: PAWPR08MB8982:EE_|AM8PR08MB6449:EE_|DBAEUR03FT057:EE_|GV2PR08MB9256:EE_ X-MS-Office365-Filtering-Correlation-Id: f3af89e5-e1aa-457f-b2ed-08daee8bb5da x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: B87iJSH19+ZkulftP0Y5IzfZpHIJkVrdAYRRg7vTpjo6h17poeruCNrl3zDwlcFhoGUOkZ2/cidvOVsbdiZYQ9M0pisGnvFKxF6hH0mgfyttH1Vv1C0117yzfggxHzNoA0k9GZl7BuSTsduj084yLCf19sKnxPnUdcCluFM1qmXwqjUVnqrxQlSoH8KC68nUI4RUfrTrB9omvn+KAQOGBxIBbM0fMLw9YsbGl98D48Nv629ycyJw/OYNv5j+ROVsHIQvMpOf0+7ay3IqLEO54UmauM+T/CkyeoTIbj165h3j/IVZpxGMRD+zteGhAc7I73x6Ce2hxi5gWlFg0BGHnf+unUifQANlxdupj5TxIboVErCmespdRu7PPbEEcFY5v3q8yakMn1xeQ0w9utgJbabbYgBk6XR/RecWj/5T1NLBtU6WZl9AyEIX27iYi5Vc+fBluEb7sozeLsWMAIk9OPdGohZkD+Aeqt7RzPiXiOMr8EQtPZbCxbuDUtvYDBlpEUlWLvbamMz+kZlYqBq3m3f4dSPD/DxvWQmHAO4qItUAhDY6bT2ASopGmuLfhnHc2tv2rFiS0oLbUGtDT4MdDMoL6GtluV81P55FnFar0u5X7pBnNqvgc8vRis0IUKWQ7wFdmJNuWUByaUA7/pQ9DeVJzmZuOAiSFsRxlb2xdv27QveJLoTe03CVD6GzMJ9CKA7JBa9nyMI/BQSzEwp6zQ== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAWPR08MB8982.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(4636009)(136003)(366004)(346002)(376002)(396003)(39860400002)(451199015)(6506007)(86362001)(38070700005)(26005)(71200400001)(7696005)(186003)(38100700002)(9686003)(478600001)(122000001)(33656002)(66446008)(55016003)(41300700001)(8936002)(83380400001)(316002)(54906003)(76116006)(66476007)(66946007)(66556008)(5660300002)(4326008)(8676002)(91956017)(64756008)(6916009)(52536014)(2906002);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB6449 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DBAEUR03FT057.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 8f708630-b8c1-45e7-a362-08daee8bad49 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 9C11ULUDzUWGH2Bbn+Fk4TbHGIpn8Kv+t92wp0XQPONfUntjeUp2MZwNrK6bH0vFKZLf+WZF5+yyDYAIkxXCt+3IdM+PG+OnmSSuIeKIvDY6w7Uakw9Poj40JaDJonhVgq6iBQfO95d714MuxO6OI6QobP3YHLD5CMtmUhG1cMTxNGz/1nygGS2BaNL91OVG0jti4OnVkyQbrnrf59NaQMkw3YZsd+gnlRYYtboIcJX/cvE4gOYyLeLFt3NYsXtTRZrMZFXdGUUSpVARSJT8bDf+Hu1lV3Y/pLWpun5GwHneMMWP41/jRyDAsegGKw43a/lhuYZWygNaWZhDP+ciyVVoSQp8R1+eD0mzyyLVsTbJX4CNg/Br8QRe3WVulIClj5DGV6YdtxSOSfLrxMvf06IuWCXJS9trbVATdB3WgMJV9lJMTNHDpFcwJw9quGHM5Bq7JVXI+46zdRc/iXRdpRJH7y0dpMZwSBmEePHhIzwOy8w1tKfUOdNx19NrVMo6mPO32CXl51DESVZCk3geuadzkMyKcxRHutreisL+90/7GVqDvTPSEZNoZNOzUfNR1o2hQbNgx1WDIrOL4on2+yn8UBaw1JkEZNCbAQpGYI1k/YBEC02G71DiObc3LqskuPNxr+keyGAYYZoUaDR2TkHMfv+cppXR1oputAQD+zGZYD0zNyGLC/nspVqbebaf19XHVVzEPJxE2Cid0900aQ== X-Forefront-Antispam-Report: CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230022)(4636009)(396003)(39860400002)(346002)(376002)(136003)(451199015)(36840700001)(46966006)(40470700004)(356005)(82740400003)(81166007)(33656002)(2906002)(40480700001)(55016003)(5660300002)(36860700001)(107886003)(186003)(83380400001)(6862004)(478600001)(26005)(82310400005)(6506007)(70586007)(8676002)(4326008)(9686003)(7696005)(70206006)(41300700001)(8936002)(40460700003)(86362001)(54906003)(52536014)(316002)(47076005)(336012);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jan 2023 19:41:44.5063 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f3af89e5-e1aa-457f-b2ed-08daee8bb5da X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DBAEUR03FT057.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR08MB9256 X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,FORGED_SPF_HELO,KAM_DMARC_NONE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,TXREP,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Alex,=0A= =0A= > I'm fine deprecating rawmemchr(3) in the manual page if you suggest it.= =A0 I don't =0A= > see any use cases for it.=A0 If you confirm, I'll do it.=0A= =0A= Yes, I don't see the point, the main use-case appears to be for s + strlen = (s) but=0A= is often slower since targets may implement it like memchr (which is more= =0A= complex than searching just for zero).=0A= =0A= > bzero(3) is much more useful than memset(3).=A0 I've only used memset(3) = for =0A= > something non-zero once in my life, IIRC.=A0 Writing bzero(p, n) is easie= r to get =0A= > right, and simpler.=0A= =0A= It may save a few keypresses but it's dead so all you're doing is confuse p= eople=0A= who have never heard of it...=0A= =0A= > mempcpy(3) is also much more useful than memcpy(3) (and in fact, It would= be =0A= > great if glibc optimized mempcpy(3) and then implemented memcpy(3) in ter= ms of it).=0A= =0A= It makes no sense at all to support memcpy in terms of mempcpy since the la= tter is=0A= rarely used. Even if is supported in a libc, it's often not optimized... So= a redesigned=0A= memcpy would obviously return 'void' as very few calls use a return value.= =0A= =0A= > bcopy(3) is already deprecated in the manual page.=A0 That function is de= ad.=0A= =0A= Good. Progress!=0A= =0A= > My opinion is that moving the responsibility of providing inline versions= of =0A= > functions to the compiler, is just a consequence of the mess that libc is= .=0A= =0A= Compilers aren't just inlining, they are *optimizing*. GLIBC string.h used = to=0A= thousands of lines of complex macros and inline functions trying to handopt= imize=0A= every special case in many string functions. I ripped it all out and the ge= nerated=0A= code is now better since the compiler optimizes it.=0A= =0A= > For example, a libc-mem microlibrary could implement:=0A= =0A= I don't get what the supposed benefit would be of having both 'p' and=0A= non-'p' variants of most of these. Yes, for some str* variants it is better= to return=0A= the end rather than the start since that can avoid an extra strlen call. Ho= wever=0A= I can't see any benefit for the mem* ones that don't return a value. It's s= imply=0A= extra overhead to return a value, which in almost all cases won't be used..= .=0A= =0A= > Having the function definitions inline allows the compiler to see the ent= ire =0A= > dependency until the primitive definitions, and optimize as much as is po= ssible.=0A= =0A= That's fine for simple syntactic sugar, but it doesn't work in complex case= s.=0A= =0A= > In some benchmark I wrote recently for a string-copying function that I p= roposed =0A= > for glibc (stpecpy(3)), this library of mine outperforms any other defini= tion of =0A= > it by a very large margin, just by making it inline.=A0 Of course, I expe= ct that =0A= > if enough code is added to GCC, using the normal definition would be as f= ast, =0A= > but the point is that this doesn't require optimizing code in the compile= r to =0A= > get really fast code.=0A= =0A= Again this works fine for syntactic sugar where the compiler will always in= line and=0A= optimize the underlying primitives. If you define new functionality or some= thing=0A= more complex (say memrchr before it existed) then how are you going to=0A= implement it efficiently in an inline function?=0A= =0A= Also you still need to add the symbol to a library as well or pay the cost = of having=0A= multiple outline copies of the same static inline function when the compile= r isn't=0A= able to inline for whatever reason. So yeah we've been there done that with= GLIBC=0A= headers, and it was a total mess. There are still exported symbols for inte= rnal inline=0A= functions that we have to keep supporting for backwards compatibility...=0A= =0A= So there are good reasons we do stuff the way we do - it works!=0A= =0A= Cheers,=0A= Wilco=