All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>
To: Florian Weimer <fweimer@redhat.com>,
	Zack Weinberg <zackw@panix.com>,
	mtk.manpages@gmail.com
Cc: linux-man@vger.kernel.org, libc-alpha@sourceware.org
Subject: Re: [PATCH] makecontext.3: Fix function declarator with empty parentheses.
Date: Fri, 5 Mar 2021 02:13:52 +0100	[thread overview]
Message-ID: <c5df9263-edb8-c50a-e691-a454d4ae833f@gmail.com> (raw)
In-Reply-To: <87v9a6hbgt.fsf@oldenburg.str.redhat.com>

Hello Zack, Florian, Michael,

On 3/4/21 8:45 PM, Alejandro Colomar wrote:
> glibc uses 'void (*f)(void)' for makecontext()'s second parameter.
>
> C11 marked function declarators with empty parentheses as
> obsolescent:
>
>
>>   6.11.6  Function declarators
>> 1 The use of function declarators with empty parentheses (not
>>   prototype-format parameter type declarators) is an obsolescent
>>   feature.

I quoted C11, but it's also in C99 (same section 6.11.6.1) and in C89
(in section 3.9.4) with the same wording.

>
>
> Let's use the correct syntax by explicitly using '(void)'.
>
> .../glibc$ grep_glibc_prototype makecontext
> stdlib/ucontext.h:51:
> extern void makecontext (ucontext_t *__ucp, void (*__func) (void),
> 			 int __argc, ...) __THROW;
> .../glibc$
>
> Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
> ---


On 3/4/21 9:10 PM, Zack Weinberg wrote:
> On Thu, Mar 4, 2021 at 2:48 PM Alejandro Colomar via Libc-alpha
> <libc-alpha@sourceware.org <mailto:libc-alpha@sourceware.org>> wrote:
>
>     glibc uses 'void (*f)(void)' for makecontext()'s second parameter.
>
>
> Did you mean ‘void (*f)()’ ?

I did actually mean 'void (*f)(void)'.  Glibc uses that for the
prototype (as you can see from my commit message (see above)), and as I
confirmed just now, it also uses that type for the definition of the
function:

[
.../glibc$ grep -rn '^makecontext\s*('
stdlib/makecontext.c:22:makecontext (ucontext_t *ucp, void (*func)
(void), int argc, ...)
.../glibc$
]

However, I should have read the manual page (I must admit that I only
read the SYNOPSIS and EXAMPLES sections of the manual page and the glibc
source before writing the patch).  It's clear that the prototype that
was being used in the manual page was more correct (in the sense that it
more accurately represented the actual expected function pointer) than
the glibc prototype (eventhough the glibc prototype is more standards
conforming).

So my patch is wrong.

Florian, should I file a bug in glibc's bugzilla?

>
>     C11 marked function declarators with empty parentheses as
>     obsolescent:
>
>
>     >   6.11.6  Function declarators
>     > 1 The use of function declarators with empty parentheses (not
>     >   prototype-format parametertype declarators) is an obsolescent
>     >   feature.
>
>
>     Let's use the correct syntax by explicitly using '(void)
>
>
> Unfortunately this change would be incorrect. makecontext’s second
> parameter really is a pointer to a function that takes any number and
> type of arguments, and there is no other way to write that in C than
> ‘void (*)()’. Which, yes, means this function cannot be declared in
> conformant C11.

Yes, you're completely right!  Thanks for noticing.


On 3/4/21 10:10 PM, Florian Weimer wrote:
> * Zack Weinberg:
> 
>> This is actually the Austin Group’s primary rationale for deprecating
>> makecontext and its relatives.
> 
> That's a bit surprising because open and fcntl have a similar problem:
> the argument type before the ellipsis cannot be int.
> 
> And doesn't a later C standard add a generic function pointer type?

Ahh, I found it.  It's not in any standard, yet, but we might see it
soon in C2x: <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2230.htm>

Actually, one of the proposals is to reuse the empty parentheses for
this generic function pointer (thus removing it as a valid function
declaration), so the current prototype used in the manual page would
still be correct.

Another proposal is to add 'funcptr_t' for that, which seems to be
compatible with older standards.

You could even use it in glibc.


Michael, please ignore this patch.


Thank you all,

Alex

-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

  reply	other threads:[~2021-03-05  1:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-04 19:45 [PATCH] makecontext.3: Fix function declarator with empty parentheses Alejandro Colomar
     [not found] ` <CAKCAbMg3G4EAeuUhN9EQTDnrTSD0sPoH0uH1=kkpfj9qYorPdg@mail.gmail.com>
2021-03-04 21:10   ` Florian Weimer
2021-03-05  1:13     ` Alejandro Colomar (man-pages) [this message]
2021-03-05 10:21       ` Florian Weimer
2021-03-05 10:27         ` Andreas Schwab
2021-03-05 12:48         ` Alejandro Colomar (man-pages)

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=c5df9263-edb8-c50a-e691-a454d4ae833f@gmail.com \
    --to=alx.manpages@gmail.com \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-man@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=zackw@panix.com \
    /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.