[BUG,211039] malloc.3: Document that realloc(p, 0) is specific to glibc and nonportable
Message ID | 20210109211505.76000-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 45FFA386102A; Sat, 9 Jan 2021 21:20:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 45FFA386102A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1610227241; bh=bZakKUDtRWm6LkM+h+KfofoStOa9aIDbIKtxnSeAxhU=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=ZWOb2am5AX4VjBcVpAlbMoa9dM7gwCa3E6+SxTOIktLTYmiYowH53ToBxt9g3DLEh 8TdfcWmmCgCDpwSdm317JEwKzyAwRBPvCRD3ttewo6IQKld7LwC5t5EKdJvsGfOJJl iQ5LMPYFrgkyeY/2e112H4og3ATVwh8jbpUD1S2A= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) by sourceware.org (Postfix) with ESMTPS id 5C1F23858018 for <libc-alpha@sourceware.org>; Sat, 9 Jan 2021 21:20:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5C1F23858018 Received: by mail-wr1-x434.google.com with SMTP id a12so12327071wrv.8 for <libc-alpha@sourceware.org>; Sat, 09 Jan 2021 13:20:38 -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=bZakKUDtRWm6LkM+h+KfofoStOa9aIDbIKtxnSeAxhU=; b=Fe+Vy+Alrru8SmE2FQ2ktIK0EwO+XPoBPY/fumUVLAzQY65Xwf2BfjksWCbBKZbzhE xYYN3/dZ5hU7ZejD4wukOObVFpx/Mnty+LofQIkU0H0zjQSw1tsZB2MjHR1hxW46rNIO rLIFM9Q4NSPbQH6aMUALRwy2F2Hxd7Gt0thb3ccScxEP/9/F0zqgT9x3pY0YJQK4y4zt NEThLF9mdiPpzi7cLwcXVNhCcoHHfjGFg8FD4B5A+ZLNZM/MOGPLIOGqDRRYOLybxgyn vhBRL1CiC18lfnGkRixPeR7Sw87wCD3WNm7x6IrXQPjgjLbhn9JZ9sHahtXt9Zwp0yHs INTQ== X-Gm-Message-State: AOAM532UnmIc6hpeb4SyWsBo5UCiacr1VuOf7WCsXaeEogiDOk7vET0J 1vInzIXEGkmObIvRWuTkyCJHJpMJrec= X-Google-Smtp-Source: ABdhPJz8wy1QEkpThCmhhJz/nFdriGrnjne4CZ80JNHBaApVeYttFwktDU80J2zTMlit0SfxNBujCQ== X-Received: by 2002:adf:9546:: with SMTP id 64mr9626451wrs.343.1610227237549; Sat, 09 Jan 2021 13:20:37 -0800 (PST) Received: from debian.vlc ([170.253.51.130]) by smtp.gmail.com with ESMTPSA id n3sm17922761wrw.61.2021.01.09.13.20.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 09 Jan 2021 13:20:37 -0800 (PST) To: mtk.manpages@gmail.com, Johannes Pfister <johannes.pfister@josttech.ch> Subject: [PATCH, BUG 211039] malloc.3: Document that realloc(p, 0) is specific to glibc and nonportable Date: Sat, 9 Jan 2021 22:15:06 +0100 Message-Id: <20210109211505.76000-1-alx.manpages@gmail.com> X-Mailer: git-send-email 2.30.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-12.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GB_TO_NAME_FREEMAIL, 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, bugzilla-daemon@bugzilla.kernel.org, libc-alpha@sourceware.org Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces@sourceware.org> |
Series |
[BUG,211039] malloc.3: Document that realloc(p, 0) is specific to glibc and nonportable
|
|
Commit Message
Alejandro Colomar
Jan. 9, 2021, 9:15 p.m. UTC
A more detailed notice is on realloc(3p).
......
$ man 3p realloc \
|sed -n \
-e '/APPLICATION USAGE/,/^$/p' \
-e '/FUTURE DIRECTIONS/,/^$/p';
APPLICATION USAGE
The description of realloc() has been modified from pre‐
vious versions of this standard to align with the
ISO/IEC 9899:1999 standard. Previous versions explicitly
permitted a call to realloc(p, 0) to free the space
pointed to by p and return a null pointer. While this be‐
havior could be interpreted as permitted by this version
of the standard, the C language committee have indicated
that this interpretation is incorrect. Applications
should assume that if realloc() returns a null pointer,
the space pointed to by p has not been freed. Since this
could lead to double-frees, implementations should also
set errno if a null pointer actually indicates a failure,
and applications should only free the space if errno was
changed.
FUTURE DIRECTIONS
This standard defers to the ISO C standard. While that
standard currently has language that might permit real‐
loc(p, 0), where p is not a null pointer, to free p while
still returning a null pointer, the committee responsible
for that standard is considering clarifying the language
to explicitly prohibit that alternative.
Bug: 211039 <https://bugzilla.kernel.org/show_bug.cgi?id=211039>
Reported-by: Johannes Pfister <johannes.pfister@josttech.ch>
Cc: libc-alpha@sourceware.org
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
---
Hi Johannes, Michael,
Thanks for the report, Johannes!
Please review that your name is correct (I guessed it from the email).
Michael, please review the wording.
Thanks,
Alex
man3/malloc.3 | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
Comments
Hi ALex, On 1/9/21 10:15 PM, Alejandro Colomar wrote: > A more detailed notice is on realloc(3p). > > ...... > > $ man 3p realloc \ > |sed -n \ > -e '/APPLICATION USAGE/,/^$/p' \ > -e '/FUTURE DIRECTIONS/,/^$/p'; > APPLICATION USAGE > The description of realloc() has been modified from pre‐ > vious versions of this standard to align with the > ISO/IEC 9899:1999 standard. Previous versions explicitly > permitted a call to realloc(p, 0) to free the space > pointed to by p and return a null pointer. While this be‐ > havior could be interpreted as permitted by this version > of the standard, the C language committee have indicated > that this interpretation is incorrect. Applications > should assume that if realloc() returns a null pointer, > the space pointed to by p has not been freed. Since this > could lead to double-frees, implementations should also > set errno if a null pointer actually indicates a failure, > and applications should only free the space if errno was > changed. > > FUTURE DIRECTIONS > This standard defers to the ISO C standard. While that > standard currently has language that might permit real‐ > loc(p, 0), where p is not a null pointer, to free p while > still returning a null pointer, the committee responsible > for that standard is considering clarifying the language > to explicitly prohibit that alternative. > > Bug: 211039 <https://bugzilla.kernel.org/show_bug.cgi?id=211039> > Reported-by: Johannes Pfister <johannes.pfister@josttech.ch> > Cc: libc-alpha@sourceware.org > Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com> Thanks. Patch applied. Cheers, Michael > --- > > Hi Johannes, Michael, > > Thanks for the report, Johannes! > Please review that your name is correct (I guessed it from the email). > > Michael, please review the wording. > > Thanks, > > Alex > > man3/malloc.3 | 18 +++++++++++++++++- > 1 file changed, 17 insertions(+), 1 deletion(-) > > diff --git a/man3/malloc.3 b/man3/malloc.3 > index d8b4da62f..467e2438a 100644 > --- a/man3/malloc.3 > +++ b/man3/malloc.3 > @@ -149,7 +149,8 @@ is equal to zero, > and > .I ptr > is not NULL, then the call is equivalent to > -.IR free(ptr) . > +.I free(ptr) > +(this behavior is nonportable; see NOTES). > Unless > .I ptr > is NULL, it must have been returned by an earlier call to > @@ -375,6 +376,21 @@ The > implementation is tunable via environment variables; see > .BR mallopt (3) > for details. > +.SS Nonportable behavior > +The behavior of > +.BR realloc () > +when > +.I size > +is equal to zero, > +and > +.I ptr > +is not NULL, > +is glibc specific; > +other implementations may return NULL, and set > +.IR errno . > +Portable POSIX programs should avoid it. > +See > +.BR realloc (3p). > .SH SEE ALSO > .\" http://g.oswego.edu/dl/html/malloc.html > .\" A Memory Allocator - by Doug Lea >
> A more detailed notice is on realloc(3p). Yes. But i think it will lead to bugs when there is a documentation that describes the behavior of realloc(), says realloc(ptr,0) will do free(ptr), says realloc() is conforming to POSIX.1-2001, POSIX.1-2008, C89, C99. But does not mention that the realloc(ptr,0) is not specified in this standards (except C89). And there are some distributions that do not include the realloc(3p) man page. On my Debian Buster (10) there is no realloc(3p) man page and man realloc goes to the malloc man page of the Linux Programmer's Manual. But maybe this is a problem of the distributions/Debian? > Thanks for the report, Johannes! > Please review that your name is correct (I guessed it from the email). Yes it is. Should i configure my name somewhere? Kind Regards Johannes Am Sa., 9. Jan. 2021 um 21:20 Uhr schrieb Alejandro Colomar <alx.manpages@gmail.com>: > > A more detailed notice is on realloc(3p). > > ...... > > $ man 3p realloc \ > |sed -n \ > -e '/APPLICATION USAGE/,/^$/p' \ > -e '/FUTURE DIRECTIONS/,/^$/p'; > APPLICATION USAGE > The description of realloc() has been modified from pre‐ > vious versions of this standard to align with the > ISO/IEC 9899:1999 standard. Previous versions explicitly > permitted a call to realloc(p, 0) to free the space > pointed to by p and return a null pointer. While this be‐ > havior could be interpreted as permitted by this version > of the standard, the C language committee have indicated > that this interpretation is incorrect. Applications > should assume that if realloc() returns a null pointer, > the space pointed to by p has not been freed. Since this > could lead to double-frees, implementations should also > set errno if a null pointer actually indicates a failure, > and applications should only free the space if errno was > changed. > > FUTURE DIRECTIONS > This standard defers to the ISO C standard. While that > standard currently has language that might permit real‐ > loc(p, 0), where p is not a null pointer, to free p while > still returning a null pointer, the committee responsible > for that standard is considering clarifying the language > to explicitly prohibit that alternative. > > Bug: 211039 <https://bugzilla.kernel.org/show_bug.cgi?id=211039> > Reported-by: Johannes Pfister <johannes.pfister@josttech.ch> > Cc: libc-alpha@sourceware.org > Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com> > --- > > Hi Johannes, Michael, > > Thanks for the report, Johannes! > Please review that your name is correct (I guessed it from the email). > > Michael, please review the wording. > > Thanks, > > Alex > > man3/malloc.3 | 18 +++++++++++++++++- > 1 file changed, 17 insertions(+), 1 deletion(-) > > diff --git a/man3/malloc.3 b/man3/malloc.3 > index d8b4da62f..467e2438a 100644 > --- a/man3/malloc.3 > +++ b/man3/malloc.3 > @@ -149,7 +149,8 @@ is equal to zero, > and > .I ptr > is not NULL, then the call is equivalent to > -.IR free(ptr) . > +.I free(ptr) > +(this behavior is nonportable; see NOTES). > Unless > .I ptr > is NULL, it must have been returned by an earlier call to > @@ -375,6 +376,21 @@ The > implementation is tunable via environment variables; see > .BR mallopt (3) > for details. > +.SS Nonportable behavior > +The behavior of > +.BR realloc () > +when > +.I size > +is equal to zero, > +and > +.I ptr > +is not NULL, > +is glibc specific; > +other implementations may return NULL, and set > +.IR errno . > +Portable POSIX programs should avoid it. > +See > +.BR realloc (3p). > .SH SEE ALSO > .\" http://g.oswego.edu/dl/html/malloc.html > .\" A Memory Allocator - by Doug Lea > -- > 2.30.0 >
On 1/11/21 11:13 AM, Johannes Pfister wrote: >> A more detailed notice is on realloc(3p). > > Yes. But i think it will lead to bugs when there is a documentation > that describes the behavior of realloc(), says realloc(ptr,0) will do > free(ptr), says realloc() is conforming to POSIX.1-2001, POSIX.1-2008, > C89, C99. > But does not mention that the realloc(ptr,0) is not specified in this > standards (except C89). > > And there are some distributions that do not include the realloc(3p) > man page. On my Debian Buster (10) there is no realloc(3p) man page > and man realloc goes to the malloc man page of the Linux Programmer's > Manual. > But maybe this is a problem of the distributions/Debian? Hi Johannes, That was the message for the commit. See commit: da116d481b79892026029b442fb381713a09f123 <https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=da116d481b79892026029b442fb381713a09f123> > >> Thanks for the report, Johannes! >> Please review that your name is correct (I guessed it from the email). > Yes it is. Should i configure my name somewhere? No, don't worry. It was only for the "Reported-by" line in the patch. Regards, Alex
diff --git a/man3/malloc.3 b/man3/malloc.3 index d8b4da62f..467e2438a 100644 --- a/man3/malloc.3 +++ b/man3/malloc.3 @@ -149,7 +149,8 @@ is equal to zero, and .I ptr is not NULL, then the call is equivalent to -.IR free(ptr) . +.I free(ptr) +(this behavior is nonportable; see NOTES). Unless .I ptr is NULL, it must have been returned by an earlier call to @@ -375,6 +376,21 @@ The implementation is tunable via environment variables; see .BR mallopt (3) for details. +.SS Nonportable behavior +The behavior of +.BR realloc () +when +.I size +is equal to zero, +and +.I ptr +is not NULL, +is glibc specific; +other implementations may return NULL, and set +.IR errno . +Portable POSIX programs should avoid it. +See +.BR realloc (3p). .SH SEE ALSO .\" http://g.oswego.edu/dl/html/malloc.html .\" A Memory Allocator - by Doug Lea