From: Alejandro Colomar <alx@kernel.org>
To: Mark Harris <mark.hsj@gmail.com>
Cc: Carlos O'Donell <carlos@redhat.com>,
"Michael Kerrisk (man7.org)" <mtk@man7.org>,
linux-man <linux-man@vger.kernel.org>
Subject: Re: Mangled function prototypes (phantom arguments)
Date: Fri, 29 May 2026 00:11:29 +0200 [thread overview]
Message-ID: <ahi9cQU7htXQNrhl@devuan> (raw)
In-Reply-To: <ahi7dckZtycvn_Ql@devuan>
[-- Attachment #1: Type: text/plain, Size: 2126 bytes --]
On 2026-05-29T00:10:23+0200, Alejandro Colomar wrote:
> Hi Mark,
>
> On 2026-05-28T14:43:21-0700, Mark Harris wrote:
> > > > My view was always that they were the simplest expression of the
> > > > interface that the widest possible audience could understand, and
> > > > that seems to align with Michael's view.
> > >
> > > That doesn't provide much value, IMHO. My opinion of the SYNOPSIS is
> > > that it's a quick reminder of how a function should be used.
> >
> > I suggest a compromise. Keep the array sizes, which are the part that
> > you claim adds value, and drop the forward declarations, which are the
> > part that confuses people. So for example:
> >
> > ssize_t read(int fd, void buf[count], size_t count);
> >
> > Yes, count is used before its definition, but the goal is not to write
> > a valid function declaration; the existing one being invalid is
> > evidence of that. It is difficult to imagine that anyone would have
> > trouble finding the definition of count without a forward declaration,
> > unless they are a compiler in which case they would also be tripped up
> > by the array-of-void.
>
> I considered doing that some time ago. I am worried about something: it
> might "work" if you're unlucky.
>
> Let's say a relatively new programmer sees this and thinks it's valid C.
> And let's say it tries it in their own code, which may have a variable
> in scope (most likely, a global one) named 'count'.
>
> extern int count;
>
> ssize_t read(int fd, void buf[count], size_t count);
>
> That's going to compile, but it's not what you'd expect.
Oh well, this one won't compile, because of void. But it would work for
other arrays, such as arrays of char.
>
> That's why I originally used [.count] notation. That one if free from
> this problem. However, GCC maintainers convinced me of using some
> syntax that is valid C (at least in the GNU dialect of it, which is the
> majoritary one anyway).
>
>
> Have a lovely night!
> Alex
>
> --
> <https://www.alejandro-colomar.es>
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-05-28 22:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-27 12:14 Mangled function prototypes (phantom arguments) Michael Kerrisk (man7.org)
2026-05-27 13:47 ` Alejandro Colomar
2026-05-27 16:46 ` Michael Kerrisk (man7.org)
2026-05-27 17:58 ` Alejandro Colomar
2026-05-28 13:06 ` Michael Kerrisk (man7.org)
2026-05-28 14:25 ` Alejandro Colomar
2026-05-28 18:39 ` Carlos O'Donell
2026-05-28 21:24 ` Alejandro Colomar
2026-05-28 21:43 ` Mark Harris
2026-05-28 22:10 ` Alejandro Colomar
2026-05-28 22:11 ` Alejandro Colomar [this message]
2026-05-28 22:56 ` Alejandro Colomar
2026-05-28 23:22 ` Mark Harris
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=ahi9cQU7htXQNrhl@devuan \
--to=alx@kernel.org \
--cc=carlos@redhat.com \
--cc=linux-man@vger.kernel.org \
--cc=mark.hsj@gmail.com \
--cc=mtk@man7.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.