From owner-freebsd-hackers@FreeBSD.ORG Mon May 27 11:46:06 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 44BA27D1 for ; Mon, 27 May 2013 11:46:06 +0000 (UTC) (envelope-from vhaisman@gmail.com) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by mx1.freebsd.org (Postfix) with ESMTP id C5E99A80 for ; Mon, 27 May 2013 11:46:05 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id r11so6683712lbv.38 for ; Mon, 27 May 2013 04:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=si9OEuknzCUOgEwNbKP6f68BuX8IgDFAIcxqNuE2ZKA=; b=K8egLS0yp3kmTHhiPEoaXwH09DGGVafE6AFLiT7HRo5+zcOj/9caUKHijkouTqoxsM VspFAkYmRCUfqIKe6CulYZjGKlIg8oVVmkgRhpDvwey52iYeKtV9nJX4vB+U3/whc+92 Yu4PyBlXpZ8Xs3MflwGTfJyBBALRA/qXimZ/EsfAcZ5G9mMmdcLe8TOZzLmwLr9S8x1f yOS8GzGlloz2mBugD8kT0rJLZG46mpKfHTPmsE+vfUxclcxcLbiaEM7BkSDlMP3B9ksq IqgUjh2Saykkdp5nb8JDjzlpvNm4Mv7xKj07cjRYF3ji/XFuXeL1PProi6jjiz7lvPYz l9Vg== MIME-Version: 1.0 X-Received: by 10.112.126.9 with SMTP id mu9mr13939501lbb.99.1369655158526; Mon, 27 May 2013 04:45:58 -0700 (PDT) Received: by 10.114.98.129 with HTTP; Mon, 27 May 2013 04:45:58 -0700 (PDT) In-Reply-To: <51A33493.9010702@platinum.linux.pl> References: <2adc4d8e7c55e92d935f61efb4c9d723@lthomas.net> <51A33493.9010702@platinum.linux.pl> Date: Mon, 27 May 2013 13:45:58 +0200 Message-ID: Subject: Re: Performance improvement to strnlen(). From: =?UTF-8?Q?V=C3=A1clav_Zeman?= To: Adam Nowacki Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 11:46:06 -0000 On 27 May 2013 12:25, Adam Nowacki wrote: > On 2013-05-27 10:37, V=C3=A1clav Zeman wrote: >> >> On 26 May 2013 21:01, Lee Thomas wrote: >>> >>> On 2013-05-26 08:00, V=C3=A1clav Zeman wrote: >>>> >>>> >>>> On 05/25/2013 10:27 PM, Lee Thomas wrote: >>>>> >>>>> >>>>> + lp =3D (const unsigned long *)((uintptr_t)str & ~LONGPTR_MASK= ); >>>>> + va =3D (*lp - mask01); >>>>> + vb =3D ((~*lp) & mask80); >>>> >>>> >>>> I do not think that this correct C. This is type punning violating the >>>> rules of the language. >>> >>> >>> >>> Hello V=C3=A1clav, >>> >>> The aliasing here is safe, because there are no writes through either o= f >>> the >>> pointers, and the reads are correctly aligned. >> >> I disagree. IANALL but AFAIK, this is simply not allowed by the >> language =3D> UB =3D> even though it seems to work in this instance, you >> are just lucky the UB is actually doing what you expect. > > > It is not possible to tell if the result would be undefined by looking at > the strnlen function alone. IMHO, it is possible to look at the strnlen() function code and see the UB there. UB is is there even if it does not manifest itself to you by producing executable that gives you unexpected results or that crashes. > Internally it doesn't break any aliasing rules > as char and long are allowed to alias. UB can only happen when the input > string was created with incompatible type (not char and not long) and the > strnlen function got inlined. No, you got it wrong here. You can access any type of object by char pointer. However the reverse is not true. > Preventing inlining would be sufficient to > guarantee correctness in any case. Preventing inlining is masking the problem but it does not make it go away. Also, in these days when compilers can optimize across translation units, you cannot be sure the UB will be masked even if no inlining happens. -- VZ