From owner-freebsd-current@FreeBSD.ORG Mon Jul 8 11:44:39 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 251D5DBE for ; Mon, 8 Jul 2013 11:44:39 +0000 (UTC) (envelope-from dt71@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by mx1.freebsd.org (Postfix) with ESMTP id B7AE81731 for ; Mon, 8 Jul 2013 11:44:38 +0000 (UTC) Received: from [192.168.1.80] ([31.46.168.1]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MQiVh-1UmZdA3VbJ-00U1zF for ; Mon, 08 Jul 2013 13:44:38 +0200 Message-ID: <51DAA5FE.4040505@gmx.com> Date: Mon, 08 Jul 2013 13:43:58 +0200 From: dt71@gmx.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: another -Wunsequenced topic References: <51CEEC34.2010308@gmx.com> <51D03D27.3020100@gmx.com> In-Reply-To: <51D03D27.3020100@gmx.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:OiFYkrsRBzVc+8rmk6w59VKPLgEmvkKW/jIlP34DwgW4gNDUi/w dkSOzqtBVm7Hc1AlEnF7wvXXGQwJm4iUbjqNscR5gY/FqaW6hSyGA8ZIrP8S3i3WixiWqk+ 5UoqBZlVmEBSPM+/feSMociGCa96IuBP7yGdjEyqyX01duQOejwe2vh86hsdSAjougKSCLx PN6Ru3nkAMjEWCq0kxGIw== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 11:44:39 -0000 Well, this turned out to be a semi-false alarm. A week ago, for a short time, there was a bug in Clang. There is no undefined behavior in ptr = func(++ptr);, partially because a function call introduces a sequence point in C, but Clang did not respect this at that time. However, x = func1(++ptr) + func2(++ptr); is compiler-dependent. Additionally, if func() turns out to be a macro, rather than a native function, then undefined behavior (due to unsequencedness) occurs. According to the manpage for ntohl(): "On machines which have a byte order which is the same as the network order, routines are defined as null macros.". This can bite libstand on big-endian systems So in the end, Clang has accidentally pointed me to an irrelated bug, and induced some unnecessary code changes. lolz