help / color / mirror / Atom feed
From: Ingo Schwarze <schwarze@usta.de>
To: Yuri Pankov <yuripv@yuripv.net>
Cc: discuss@mandoc.bsd.lv
Subject: Re: "WARNING: parenthesis in function name" correctness
Date: Tue, 10 Sep 2019 19:47:07 +0200	[thread overview]
Message-ID: <20190910174707.GD6626@athene.usta.de> (raw)
In-Reply-To: <421eeed3-8da5-b852-4581-1058de113831@yuripv.net>

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?

> ...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 "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.

 To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv

  reply	other threads:[~2019-09-10 17:47 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 [this message]
2019-09-10 22:43   ` Yuri Pankov
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190910174707.GD6626@athene.usta.de \
    --to=schwarze@usta.de \
    --cc=discuss@mandoc.bsd.lv \
    --cc=yuripv@yuripv.net \
    --subject='Re: "WARNING: parenthesis in function name" correctness' \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).