From: Yuri Pankov <yuripv@yuripv.net>
To: Ingo Schwarze <schwarze@usta.de>
Cc: discuss@mandoc.bsd.lv
Subject: Re: "WARNING: parenthesis in function name" correctness
Date: Wed, 11 Sep 2019 01:43:22 +0300 [thread overview]
Message-ID: <a80abcfc-e8bd-e7ee-060c-eb4ba6d53caf@yuripv.net> (raw)
In-Reply-To: <20190910174707.GD6626@athene.usta.de>
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
next prev parent reply other threads:[~2019-09-10 22:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-10 8:20 Yuri Pankov
2019-09-10 17:47 ` Ingo Schwarze
2019-09-10 22:43 ` Yuri Pankov [this message]
2019-09-13 19:31 ` Ingo Schwarze
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a80abcfc-e8bd-e7ee-060c-eb4ba6d53caf@yuripv.net \
--to=yuripv@yuripv.net \
--cc=discuss@mandoc.bsd.lv \
--cc=schwarze@usta.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).