From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Fix use of sockaddr_in Date: Sat, 27 May 2017 11:35:59 +0000 Message-ID: References: <83shk989r5.fsf@gnu.org> <20170513150837.31184-1-phst@google.com> <83h90o8zt9.fsf@gnu.org> <877f1kefhi.fsf@linux-m68k.org> <83a86g8siw.fsf@gnu.org> <87y3u0cyjy.fsf@linux-m68k.org> <838tm088yj.fsf@gnu.org> <8337c78qq6.fsf@gnu.org> <034ef5c4-8bb1-264a-f1f4-46789d2d98c3@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113ad7b840bb8c05507fdc70" X-Trace: blaine.gmane.org 1495885019 15381 195.159.176.226 (27 May 2017 11:36:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 27 May 2017 11:36:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert , Philipp Stephani , Eli Zaretskii , Andreas Schwab Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 27 13:36:55 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dEa1e-0003qC-D9 for ged-emacs-devel@m.gmane.org; Sat, 27 May 2017 13:36:54 +0200 Original-Received: from localhost ([::1]:40313 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dEa1i-0001P3-Cs for ged-emacs-devel@m.gmane.org; Sat, 27 May 2017 07:36:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54576) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dEa12-0001On-Jy for emacs-devel@gnu.org; Sat, 27 May 2017 07:36:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dEa11-0003CJ-Kd for emacs-devel@gnu.org; Sat, 27 May 2017 07:36:16 -0400 Original-Received: from mail-oi0-x230.google.com ([2607:f8b0:4003:c06::230]:32795) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dEa0w-00038G-Nb; Sat, 27 May 2017 07:36:10 -0400 Original-Received: by mail-oi0-x230.google.com with SMTP id w10so39012943oif.0; Sat, 27 May 2017 04:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9FzmXoxGdWzAyyHmMUlduaszRDbsCjRdhjKVmCXI0RY=; b=MMEG9TkSMogTh6TXvOmKHaXEtEDrQ07FODyKia8e2t5yDQFWGy/n7/ofCP+s1eNEoK laEAfMdRhvBnmjaJSApVCt1irfYiSLJweCaI74IzBS+bbC74ScxXSoTfbr0wu4upEYLB scQi/zKQIPYk/z/CdpEAOJtu86+PaRKpMEvA/TEIkMXXWMRZ6lJYWzzRWlhqdNUQ89Zp SAPITovqazevlJ0BWnvlOiuoJToJ2dDJxQ3s2BemXnlj8xrsedWyIdKRcx63XB1gnM35 sRSEJErzeHUf/UYMroiy/lyBBVP6HN/8MZSXeT3yiWSMAB32bq1V+wXFy5KzfyjgGVeV MrsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9FzmXoxGdWzAyyHmMUlduaszRDbsCjRdhjKVmCXI0RY=; b=NHAKMRkMyuqSOguF1iX9pzSZvBMPjpbaRrvF88jSPAoKLvX6+biNjTRhVTxUBrXQCQ XqRHgktm84gsJna8QTFcjNzVSoiwnw00PH3iH7yXwNmo4aNd5ff+M6Qcpw0ulIonISpa Vm6NDqOAYvwGbzy+lxLNU6YFg9arM0dCCwVeVzIq4DWLbwTQ7QYu6BX2pP9z+DIwadK8 3CHMXBlpkb+kcOXYddIFcENXAhygxclTDPBDb5d5QG8rVE1YT0bNqp9T0dYk9Fqf1laf WVCcXLGd/izaDPzPKDNiqb0c/cNIXUS8OSGSPkuLlbx9a+bcidQ5roSx8oJYNUBX8Kbc QPmg== X-Gm-Message-State: AODbwcCmOTGUbjf9cJFlkQbs6WKZ12cQpP9lwINGrmne0RmcbSknEd9A Rox8Y6GCLKCSaPunvbzL4ytZ6Fu5rA== X-Received: by 10.202.87.76 with SMTP id l73mr2623669oib.191.1495884969850; Sat, 27 May 2017 04:36:09 -0700 (PDT) In-Reply-To: <034ef5c4-8bb1-264a-f1f4-46789d2d98c3@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4003:c06::230 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:215263 Archived-At: --001a113ad7b840bb8c05507fdc70 Content-Type: text/plain; charset="UTF-8" Paul Eggert schrieb am Mi., 17. Mai 2017 um 22:38 Uhr: > On 05/15/2017 02:04 AM, Philipp Stephani wrote: > > - Maybe add verify(INT_MAX >= TYPE_MAXIMUM(in_port_t)) and > > verify(TYPE_MINIMUM(in_port_t) == 0) to make sure that we can use int > > for the port? > > The code has been changed so that the port number is no longer stored in > an int so this remark is obsolete now. However, if this issue crops up > later I don't think we need to worry about it for IPv4 and IPv6 ports, > since they're always in the range 0..65535. Emacs already assumes that > 'int' is at least 32 bits wide, as per POSIX. > Yes, these static assertions are more for documenting the assumptions that the code makes in a way that actually checks the assumptions. > > > - Should there be a guard against the alias violation, e.g. by > > declaring sa and sa1 with __attribute__((may_alias))? Otherwise it's > > UB and the compiler might elide the switch entirely. > > Yes, that is easy enough to do and would avoid some unlikely but > hard-to-catch bugs. I installed the attached. Most likely other parts of > Emacs should use may_alias too; do you happen to have any tool in your > toolbox that would find them systematically? > > A type-based aliasing sanitizer is currently being added to Clang. Once that is landed I'll run it over the Emacs codebase. --001a113ad7b840bb8c05507fdc70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Paul E= ggert <eggert@cs.ucla.edu> = schrieb am Mi., 17. Mai 2017 um 22:38=C2=A0Uhr:
On 05/15/2017 02:04 AM, Philipp Stephani wrote:
> - Maybe add verify(INT_MAX >=3D TYPE_MAXIMUM(in_port_t)) and
> verify(TYPE_MINIMUM(in_port_t) =3D=3D 0) to make sure that we can use = int
> for the port?

The code has been changed so that the port number is no longer stored in an int so this remark is obsolete now. However, if this issue crops up
later I don't think we need to worry about it for IPv4 and IPv6 ports,<= br> since they're always in the range 0..65535. Emacs already assumes that<= br> 'int' is at least 32 bits wide, as per POSIX.
=
Yes, these static assertions are more for documenting the as= sumptions that the code makes in a way that actually checks the assumptions= .
=C2=A0

> - Should there be a guard against the alias violation, e.g. by
> declaring sa and sa1 with __attribute__((may_alias))? Otherwise it'= ;s
> UB and the compiler might elide the switch entirely.

Yes, that is easy enough to do and would avoid some unlikely but
hard-to-catch bugs. I installed the attached. Most likely other parts of Emacs should use may_alias too; do you happen to have any tool in your
toolbox that would find them systematically?


A type-based aliasing sanitizer is cur= rently being added to Clang. Once that is landed I'll run it over the E= macs codebase.
--001a113ad7b840bb8c05507fdc70--