From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43555 invoked by alias); 25 Oct 2016 16:46:16 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 43534 invoked by uid 89); 25 Oct 2016 16:46:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: eu-smtp-delivery-143.mimecast.com From: Wilco Dijkstra To: "adhemerval.zanella@linaro.org" , "Andreas Schwab" CC: "libc-alpha@sourceware.org" , nd Subject: Re: [PATCH] Fix undefined behaviour inconsistent for strtok Date: Tue, 25 Oct 2016 16:46:00 -0000 Message-ID: References: In-Reply-To: x-ms-office365-filtering-correlation-id: ef0cd18f-6d18-4804-5e6d-08d3fcf6662a x-microsoft-exchange-diagnostics: 1;AM5PR0802MB2612;7:icADPeLjzCHjRLq+fZyOFA8osQFKSiotYr2uWXnXJxk1mEAE6SYStXpf2CKVP7xwOVJBC1gexLK7JWP5JG8Lw56E9ovlInG2mIINx4eMGps0ERpRgZTFbR6nwj6y02oZMGd3aYIXgrEKFC3Kd6QKUuAzLQWahy/SMKYLdV5SuBiZeO2cny+gmJiP2gvOP/hcbUdIOWDayP93LtgprOw5vScs5Ma+V/OScPzqOiqlYVIWBvJGaUM8jzsyNe9uTaHnpQhag9Y0HhuHmTu+61Lawa5eCoVf6ofu9Lz8U1Jd1ej8zqqb6ntOEvGV3XwPWdX/tCE26eY465NuQ5tqBboCuK8HEz93gCSezl1hz4qjMWA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0802MB2612; nodisclaimer: True x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026);SRVR:AM5PR0802MB2612;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0802MB2612; x-forefront-prvs: 01068D0A20 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(7916002)(199003)(189002)(9686002)(76576001)(102836003)(2906002)(77096005)(101416001)(7736002)(2501003)(7846002)(7696004)(4326007)(66066001)(74316002)(87936001)(3280700002)(3660700001)(8936002)(92566002)(105586002)(50986999)(81166006)(189998001)(81156014)(86362001)(2900100001)(68736007)(5001770100001)(33656002)(10400500002)(2950100002)(76176999)(122556002)(54356999)(97736004)(106356001)(5660300001)(6116002)(305945005)(586003)(3846002)(11100500001)(106116001)(8676002)(5002640100001);DIR:OUT;SFP:1101;SCL:1;SRVR:AM5PR0802MB2612;H:AM5PR0802MB2610.eurprd08.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2016 16:45:59.4037 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0802MB2612 X-MC-Unique: RTJHIjocNyatFm-WpV3oxA-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2016-10/txt/msg00433.txt.bz2 Hi, >+=A0 if ((s =3D=3D NULL) && ((s =3D olds) =3D=3D NULL)) >+=A0=A0=A0 return NULL; > > What is the benefit of this given: > > if (s =3D=3D NULL) > /* This token finishes the string. */ > olds =3D __rawmemchr (token, '\0'); Right, looking at this a bit more, if we call strcspn rather than strpbrk, we get the end of the string for free and avoid 2 calls. It looks like the reason behind the (s =3D olds) =3D=3D NULL check is purely performance. Checking *s =3D=3D '\0' at the start is slightly faster still = (and would seem better as it catches incorrect use of strtok). With these changes you get > 2x speedup for most cases. I'll post a patch. Wilco