From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by sourceware.org (Postfix) with ESMTPS id 95E55385800D for ; Sun, 10 Jan 2021 08:19:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 95E55385800D Received: by mail-ed1-x531.google.com with SMTP id cm17so15620093edb.4 for ; Sun, 10 Jan 2021 00:19:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:cc:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TixBGChSba/HSSHbBr4AvaSWEWy1LsD7obi+efVmqT0=; b=aeUnoAZlpyIjTD53Ob2f5hyP7N7wm3XLHgndJqmZ2j2mdxk4in3hcJlxLKbJuj5Yld ZTLIspcmaoQuT2xrzgLWdAUoou4sF/+B54CfGmHz5B6gdtuEwMNc729PRTKnllOn/LK1 NKDj2aSPOTptX+cGECOtuyvoRnbWqNQGxXfy17sBBhbNbbaZiuaN5pZvkyPZ+Kacd1YZ Iga8GSUHQ1zPF1jeBvmTX0+pHdAO9sDULVaMOvQWRxVU9dCCxRy3gJuXZwH9tyz36XXS LI9RwycRAo7e/gtaXH0cj9i2BYjAj0lMxwEhj2GLAVPq6nvhLfCD5vgj0CAHeyMEHZCu eQaA== X-Gm-Message-State: AOAM531w8XzQcBPqTD+yEjrh/5Pd2BdRA2j8+L6RIuIlT5E2HUas91HF Rwba7B5oyHUbNEm0s9db06PyFjRXv3Y= X-Google-Smtp-Source: ABdhPJx/gPwhSTzkb8Zv5bJ5tOKNmpi6G9FX/G6xiS4tc0kBWrI3Tw5CcmCoxedm6Ipn3saKnzpm3A== X-Received: by 2002:aa7:d407:: with SMTP id z7mr11259649edq.234.1610266756192; Sun, 10 Jan 2021 00:19:16 -0800 (PST) Received: from ?IPv6:2001:a61:244d:fe01:9fb1:d962:461a:45e8? ([2001:a61:244d:fe01:9fb1:d962:461a:45e8]) by smtp.gmail.com with ESMTPSA id rk12sm5453397ejb.75.2021.01.10.00.19.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 10 Jan 2021 00:19:15 -0800 (PST) Cc: mtk.manpages@gmail.com, linux-man@vger.kernel.org, bugzilla-daemon@bugzilla.kernel.org, libc-alpha@sourceware.org Subject: Re: [PATCH, BUG 211039] malloc.3: Document that realloc(p, 0) is specific to glibc and nonportable To: Alejandro Colomar , Johannes Pfister References: <20210109211505.76000-1-alx.manpages@gmail.com> From: "Michael Kerrisk (man-pages)" Message-ID: Date: Sun, 10 Jan 2021 09:19:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20210109211505.76000-1-alx.manpages@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-10.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, URI_DOTEDU 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2021 08:19:19 -0000 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 > Reported-by: Johannes Pfister > Cc: libc-alpha@sourceware.org > Signed-off-by: Alejandro Colomar 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 > -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/