From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id eaebcc0b for ; Tue, 10 Sep 2019 17:43:26 -0500 (EST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.nyi.internal (Postfix) with ESMTP id 6D32F1076; Tue, 10 Sep 2019 18:43:25 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 10 Sep 2019 18:43:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuripv.net; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=s LWMgJsdbhSCdYtVdnNd9s+2zpox4MxiTl0KVCPu1Zc=; b=b8EbhIuJUqCSDuHMs HDLpdANYLpN1efpbyoPtJGvaYGmFZSFbLaOzs1gZJOwuqWtsjAkrQX3A431YXXT0 lim0WKso35kJC2d9D/hLZ8xvQNuL3XR5wwroh2RyIKnsSmRfQeOBHZMVkPtHv5F8 9uoSpB1ozMxB0LLPUYaIPFlRyceHuNrZ2oBCWxydpNMbSqCwVPeDdz8fPH9w9Vjv lgGLQVcDPOnCYyzNk+6idffTQXbf2Ee3BjXEAo1obImS7Ax/9bIw02NGrs+JvPHb G6Sm2GYrRZHPRGSAlbxWXBktCd8bu1esbZfpDf4PQhgdKJ9uIzHe0nv8tbR/ZSQM nOJ8w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=sLWMgJsdbhSCdYtVdnNd9s+2zpox4MxiTl0KVCPu1 Zc=; b=OnkV/jdEYRr7835zJbPrgRxLIO8FmJf63ypCs5EzBHAKGkHyQZdv0keL7 yA0Za20/d09WuMIH3hB9umTsQDFMmOTgkzrqLLt2kxhSAkDfONf3xcSo+CGMmDab QSfjFYufJUQWgK/XsMEczL8Jw3M+NQ5QJfJGiVHr3qzqxigJ/RqiUBEsh/POZfnw B6iov1htNROxV9wyFBVoUKDL/oXlfknHk3qOYgTpHycBfI/id1YtItFhbzFd02K0 V/kcimYP9/3/07+rs1dS7ZppnuOuK7QsI6ccoK3UFp8QQ9L0zuogt758UvNNRknc 9SwtIYVXFDbnP+uFXFWd7k56gyPKg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrtddugdduvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenog fuphgrmhfkphdqohhuthculdehtddtmdenucfjughrpefuvfhfhffkffgfgggjtgfgseht jeertddtfeejnecuhfhrohhmpegjuhhrihcurfgrnhhkohhvuceohihurhhiphhvseihuh hrihhpvhdrnhgvtheqnecuffhomhgrihhnpehmvggrnhdrfhhonecukfhppedvudejrddu geeirdekvddrudeggeenucfrrghrrghmpehmrghilhhfrhhomhephihurhhiphhvseihuh hrihhpvhdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from [192.168.1.11] (unknown [217.146.82.144]) by mail.messagingengine.com (Postfix) with ESMTPA id F1C9B8005B; Tue, 10 Sep 2019 18:43:23 -0400 (EDT) Subject: Re: "WARNING: parenthesis in function name" correctness To: Ingo Schwarze Cc: discuss@mandoc.bsd.lv References: <421eeed3-8da5-b852-4581-1058de113831@yuripv.net> <20190910174707.GD6626@athene.usta.de> From: Yuri Pankov Message-ID: Date: Wed, 11 Sep 2019 01:43:22 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.0 X-Mailinglist: mandoc-discuss Reply-To: discuss@mandoc.bsd.lv MIME-Version: 1.0 In-Reply-To: <20190910174707.GD6626@athene.usta.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Ingo Schwarze wrote: > Hi Yuri, > > Yuri Pankov wrote on Tue, Sep 10, 2019 at 11:20:24AM +0300: > >> I'm looking into fixing sbuf.9 which currently has somewhat unreadable: >> >> .Ft typedef\ int ( sbuf_drain_func ) ( void\ *arg, const\ char\ *data, >> int\ len ) ; > > Indeed, that is horrible and should be fixed. > >> ...into somewhat nicer: >> >> .Ft typedef int >> .Fo (sbuf_drain_func) >> .Fa "void *arg" >> .Fa "const char *data" >> .Fa "int len" >> .Fc >> >> ...but that gives me a: >> >> mandoc: share/man/man9/sbuf.9:69:5: WARNING: parenthesis in function >> name: (sbuf_drain_func) >> >> Looking at the code, parenthesis are only allowed in the following form: >> >> .Ft (*func_ptr) > > I think you mean .Fo/.Fn, not .Ft, right? Yes, I was thinking about .Fo, sorry. >> ...while here we don't have a "*" -- it's the way it's typedef'ed in the >> source, and I want to follow it, so I wonder if that check/warning is >> really useful. > > If i understand the C standard correctly (otherwise, please somebody > correct me!), we have: > > int (f)() -- function returning int > int (*fp)() -- pointer to function returning int > > In many situations, both can be used interchangeably, consider for > example C89 3.2.2.1: "A function designator is an expression that > has function type. Except when it is the operand of the sizeof > operator or the unary & operator, a function designator with type > ``function returning type'' is converted to an expression that has > type ``pointer to function returning type.''" > > Then again, it seems for sizeof(), it may make a difference whether > a type is a function type or a function pointer type, and maybe there > are also other situations where that matters. > > So i suspect you are right there are legitimate reasons for making > the difference in the documentation, too, > and saying ".Fo (sbuf_drain_func)" looks reasonable. > Do others agree? > > I plan to suppress the warning for ".Fo (f)" just like for ".Fo (*f)" > in the future. The likely typo that should be warned about > is ".Fo f()", and that warning will still work. Sounds good, thank you! -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv