Message ID | 20210304194534.130735-1-alx.manpages@gmail.com |
---|---|
State | Not applicable |
Headers |
Return-Path: <libc-alpha-bounces@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 688E1386F46E; Thu, 4 Mar 2021 19:48:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 688E1386F46E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1614887291; bh=1hQkoDfbSIdVgOU/Sd2EwzsscbUsImiOzy+OECzLLBM=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=K+MBNAVH77tbqH2DWZKjKIb1PMdjCsxnmAwMIrZhAgBG2Ym5ZKe9/O+usyR8OXzCS uc9hWsvOpiv0T1pda6u6rc7UoDRMxIQptxIJa1rpfOBELnjn42Vb3iEatL3eE+OwGR qzTVJohj24pJBN00w6PLUY1bqr03aEwFFrBSabEA= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) by sourceware.org (Postfix) with ESMTPS id 9D6053854814 for <libc-alpha@sourceware.org>; Thu, 4 Mar 2021 19:48:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9D6053854814 Received: by mail-wm1-x32e.google.com with SMTP id u187so9102439wmg.4 for <libc-alpha@sourceware.org>; Thu, 04 Mar 2021 11:48:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=1hQkoDfbSIdVgOU/Sd2EwzsscbUsImiOzy+OECzLLBM=; b=iom5GgA4rQCxGzrqSS+whxGM/S+DpAzKnJAwvg8r5m9vRe+nuUxchSeQqdbGFTfV0x mJL1WPmngrJCwQMT11jGx6U5bNvTzIcP//UDPNXJJrhmyiHpG7vA19lKAA644ly9gm0v KuQWqOMgr5sKJ8p0eN04w1MH2BXH1utc/K/emkMlllRStnBe61JjxohFTubaMQW4xxPO Y2VkQ0QrgT44Ax+SmlZ/cQgyjmboHXqg6NvnGKZpNghADwZ5IXbo/VUd9uasZ3zTGBaI WbfnXXZnj9qLnKr5BezLUcCsI/mipnl40srJ8U+g2XJ9gNdISlEr3hgrm5J4zLJVSO/N ZrIg== X-Gm-Message-State: AOAM532c19NSi42p3bfEdxQVoQasLnqNBWMLnI+IubnDz85YmlSaJvkN gMiOMHRCFx34fjHAcuCv6jw= X-Google-Smtp-Source: ABdhPJwvPmYaRCDgobJSGCvZhotznEQvDp0OTDBKOT1ZAeGQRWLF8vaYDNhdX264mN2ZWF2rGha0zw== X-Received: by 2002:a7b:cbcd:: with SMTP id n13mr5442836wmi.112.1614887284660; Thu, 04 Mar 2021 11:48:04 -0800 (PST) Received: from localhost.localdomain ([170.253.51.130]) by smtp.googlemail.com with ESMTPSA id z188sm763787wme.32.2021.03.04.11.48.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Mar 2021 11:48:04 -0800 (PST) To: mtk.manpages@gmail.com Subject: [PATCH] makecontext.3: Fix function declarator with empty parentheses. Date: Thu, 4 Mar 2021 20:45:35 +0100 Message-Id: <20210304194534.130735-1-alx.manpages@gmail.com> X-Mailer: git-send-email 2.30.1.721.g45526154a5 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-12.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: Alejandro Colomar via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Alejandro Colomar <alx.manpages@gmail.com> Cc: Alejandro Colomar <alx.manpages@gmail.com>, linux-man@vger.kernel.org, libc-alpha@sourceware.org Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces@sourceware.org> |
Series |
makecontext.3: Fix function declarator with empty parentheses.
|
|
Commit Message
Alejandro Colomar
March 4, 2021, 7:45 p.m. UTC
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 parametertype declarators) is an obsolescent > feature. 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> --- man3/makecontext.3 | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Comments
On Thu, Mar 4, 2021 at 2:48 PM Alejandro Colomar via Libc-alpha < libc-alpha@sourceware.org> wrote: > glibc uses 'void (*f)(void)' for makecontext()'s second parameter. Did you mean ‘void (*f)()’ ? 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. This is actually the Austin Group’s primary rationale for deprecating makecontext and its relatives. zw >
* 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? Thanks, Florian
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: > 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? I don't know. SUSv2 has (void *func) (), which would make this a glibc bug. I'm not sure if I have easy access to POSIX.1 from 2001, which I believe still has this function. I am not sure if all glibc implementations of makecontext can be used to call variadic functions. Thanks, Florian
On Mär 05 2021, Florian Weimer via Libc-alpha wrote: > I don't know. SUSv2 has (void *func) (), which would make this a glibc > bug. I'm not sure if I have easy access to POSIX.1 from 2001, which I > believe still has this function. https://pubs.opengroup.org/onlinepubs/009695399/functions/makecontext.html Andreas.
Hi Florian, On 3/5/21 11:21 AM, Florian Weimer wrote: > * Alejandro Colomar: >> Florian, should I file a bug in glibc's bugzilla? > > I don't know. SUSv2 has (void *func) (), which would make this a glibc > bug. I'm not sure if I have easy access to POSIX.1 from 2001, which I > believe still has this function. > > I am not sure if all glibc implementations of makecontext can be used to > call variadic functions. I reported the bug: <https://sourceware.org/bugzilla/show_bug.cgi?id=27523> Thanks, Alex
diff --git a/man3/makecontext.3 b/man3/makecontext.3 index 83720dd2c..ac9afcf69 100644 --- a/man3/makecontext.3 +++ b/man3/makecontext.3 @@ -32,7 +32,8 @@ makecontext, swapcontext \- manipulate user context .nf .B #include <ucontext.h> .PP -.BI "void makecontext(ucontext_t *" ucp ", void (*" func ")(), int " argc ", ...);" +.BI "void makecontext(ucontext_t *" ucp ", void (*" func ")(void), int " argc \ +", ...);" .BI "int swapcontext(ucontext_t *" oucp ", const ucontext_t *" ucp ); .fi .SH DESCRIPTION