From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id AB7453858CDA for ; Tue, 11 Jul 2023 00:32:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AB7453858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org References: <20230710220659.3501429-2-xry111@xry111.site> User-agent: mu4e 1.10.4; emacs 29.0.92 From: Sam James To: Siddhesh Poyarekar Cc: Xi Ruoyao , Adhemerval Zanella Netto , Carlos O'Donell , Alex Colomar , Andreas Schwab , Zack Weinberg , Jeff Law , libc-alpha@sourceware.org Subject: Re: [PATCH] Revert "libio: Add __nonnull for FILE * arguments of fclose and freopen" Date: Tue, 11 Jul 2023 01:31:35 +0100 In-reply-to: Message-ID: <87sf9vxp74.fsf@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-9.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,KAM_SHORT,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Siddhesh Poyarekar writes: > On 2023-07-10 18:07, Xi Ruoyao wrote: >> This reverts commit 71d9e0fe766a3c22a730995b9d024960970670af. >> Apparantly the maintainers do not like __nonnull. And I'm too >> pissed >> off to work on this anymore. Anyway I don't care about the analyzer so >> they can just add these as ugly special analyzer patterns. And I'm not >> so stupid to pass NULL to these things myself, so lacking a warning is >> not a problem to me. > > Sorry you feel this way, but this is still unresolved as we don't have > a consensus yet. However I understand if you're frustrated and don't > want to work on this for now; I do hope you return though. > > In any case, if the consensus does steer towards never using > __nonnull__, it'll likely be better to do it by hacking cdefs.h to > expand __nonnull to nothing. Right. We'd need to cull it entirely (and I'm not convinced that's the right thing to do). Xi Ruoyao's filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110617 too, to which I'm going to add some context in a moment. > > Thanks, > Sid > >> Signed-off-by: Xi Ruoyao >> --- >> libio/stdio.h | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> diff --git a/libio/stdio.h b/libio/stdio.h >> index 4cf9f1c012..2387590d6a 100644 >> --- a/libio/stdio.h >> +++ b/libio/stdio.h >> @@ -180,7 +180,7 @@ extern int renameat2 (int __oldfd, const char *__old, int __newfd, >> This function is a possible cancellation point and therefore >> not >> marked with __THROW. */ >> -extern int fclose (FILE *__stream) __nonnull ((1)); >> +extern int fclose (FILE *__stream); >> #undef __attr_dealloc_fclose >> #define __attr_dealloc_fclose __attr_dealloc (fclose, 1) >> @@ -269,7 +269,7 @@ extern FILE *fopen (const char *__restrict __filename, >> marked with __THROW. */ >> extern FILE *freopen (const char *__restrict __filename, >> const char *__restrict __modes, >> - FILE *__restrict __stream) __wur __nonnull ((3)); >> + FILE *__restrict __stream) __wur; >> #else >> # ifdef __REDIRECT >> extern FILE *__REDIRECT (fopen, (const char *__restrict __filename, >> @@ -290,7 +290,7 @@ extern FILE *fopen64 (const char *__restrict __filename, >> __attribute_malloc__ __attr_dealloc_fclose __wur; >> extern FILE *freopen64 (const char *__restrict __filename, >> const char *__restrict __modes, >> - FILE *__restrict __stream) __wur __nonnull ((3)); >> + FILE *__restrict __stream) __wur; >> #endif >> #ifdef __USE_POSIX