From patchwork Sat Jan 9 21:15:06 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Alejandro Colomar X-Patchwork-Id: 41688 Return-Path: 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 ; 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 ; 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 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Alejandro Colomar via Libc-alpha From: Alejandro Colomar Reply-To: Alejandro Colomar Cc: Alejandro Colomar , linux-man@vger.kernel.org, bugzilla-daemon@bugzilla.kernel.org, libc-alpha@sourceware.org Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" 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 --- 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