From owner-svn-src-head@freebsd.org Wed Jun 6 12:28:44 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6EC1DFF42F6; Wed, 6 Jun 2018 12:28:44 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id 802E371F8D; Wed, 6 Jun 2018 12:28:43 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id E5E97D66E9F; Wed, 6 Jun 2018 22:28:31 +1000 (AEST) Date: Wed, 6 Jun 2018 22:28:29 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Benjamin Kaduk cc: Ravi Pokala , Mateusz Guzik , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r334702 - head/sys/sys In-Reply-To: Message-ID: <20180606220347.N3528@besplex.bde.org> References: <201806060508.w56586c9053686@repo.freebsd.org> <6E6E92B2-7536-4281-8EAF-72823E84902E@panasas.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=cIaQihWN c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=mDV3o1hIAAAA:8 a=ltDKUUI1AAAA:8 a=IgBFj9cdW9r1GCZ3iiAA:9 a=CjuIK1q_8ugA:10 a=21gvIwNvQA8A:10 a=IjZwj45LgO3ly-622nXo:22 a=_FVE-zBwftR9WsbkzFJk:22 a=zPa3363zVR52QbuIqfxu:22 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 12:28:44 -0000 On Wed, 6 Jun 2018, Benjamin Kaduk wrote: > On Wed, Jun 6, 2018 at 6:35 AM, Ravi Pokala wrote: > >> Hi Mateusz, >> ... >>> ... >>> #ifdef _KERNEL >>> #define malloc(size, type, flags) ({ >> \ >> >> Now that I'm taking another look at this, I'm confused as to why the >> entire macro expansion is inside parentheses? (The braces make sense, since >> this is a block with local variables which need to be contained.) > > This is a gcc (and clang) extension to allow the macro body to be a code > block -- standard C gets unhappy with just the curly braces. > https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html is a maybe-relevant > page that google found me. Not really. This is a syntax error which is only accepted by broken compilers, since the language standard is doubly mis-specified by hard-coding it to a wrong value using CSTD=c89 in kern.mk. This asks for c99 with no extensions, but many extensions are needed. These bugs are missing in the corresponding userland makefile bsd.sys.mk. That uses CSTD?=gnu99. This asks for c99 with gnu extensions, which is what is needed, but allows the user to ask for another standard by setting CSTD. To allow the user to ask for c99, or just to not depend on compiler bugs when kern.mk asks for c99, use of this and other extensions should be marked with __extension__, as is most often done for this particular extension. Braces in macros are perfectly standard. The extension is to allow a compound statement (delimited by braces) to return a value. This is done by enclosing the statement in parentheses. The value of the statement is the value of the last expression in it. This is an extension of c99, since in c99 about the only things that can be enclosed in parentheses are expressions, but general statements are not expressions. Especially compound statements. This used to be properly documented (in installed documentation) in /usr/share/info/gcc.info.gz. Bruce