From patchwork Thu Jun 19 00:42:14 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Alejandro Colomar X-Patchwork-Id: 114706 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 1C58C3946563 for ; Thu, 19 Jun 2025 00:43:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1C58C3946563 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=OrlKU98o X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by sourceware.org (Postfix) with ESMTPS id ADD9A3924B3C for ; Thu, 19 Jun 2025 00:42:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ADD9A3924B3C Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=kernel.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org ADD9A3924B3C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=147.75.193.91 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1750293744; cv=none; b=d3Q1U5LsXFa6eT1stobLww4pNJyWry8UxLWYFx9ZwAOwwobgHyo7nmLUQmYqP+y0Vvw1af++My/pXbQ+Q7VQnGxRsAaXXHHrIQFziOaChNKcXHqrbwit2HWPOaFn9TnlKfNE3krEp97Jub2lAPlYbLLcksnU8XXHKDZ8XGRWCfA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1750293744; c=relaxed/simple; bh=0meumt5PH8YbeVhDP17AdefslLwLQeoE66/W4SNjyyU=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=PX2a9r6114AGtw/JAVXpxI23y43uznRwgdqmSyljtDFJn5xao+KbqXjAE/NKRnv08PUzaLcZSX1xeFt7fgONkrNsp72FzWagKxilqm38SOZEVpIPTNThVrQ5ikQis+MNDW1jUe7+vjGfBP9M4rmQtmlRFOpz1EECgrZhTPSujSU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ADD9A3924B3C Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 594BCA52B0D; Thu, 19 Jun 2025 00:42:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4AACFC4CEE7; Thu, 19 Jun 2025 00:42:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1750293744; bh=0meumt5PH8YbeVhDP17AdefslLwLQeoE66/W4SNjyyU=; h=Date:From:To:Cc:Subject:From; b=OrlKU98oY19AHHR31FLTFSxMilt5wXsj/A5nw3uR0jVoHXVfL8c00m2FhWVaZzu7O EfcXmE9xi7ZjbCqsjTVA4UEp4SbkWK7WHVNvs4xTvEZIMk0LVngPM2mMiHekW9LgZd P1UZ011IrIOszK830Yz76EV6yhtnz1F4UQrJRgTM3yhcMD9Z/t+cwLWzdIvSBUdtsY gItm7p/YB0IaA1CICwMOy4PRDT9NTY1asPqq+hkc3SPUU+0BNyzbdJE5q0eoBOWDDb ZzCZ2RN2GQ98YYtfoMEbkI7w+K+NIpNqsssHpR8fmDp/TjuWv+obwzWMTLg2RN8Yil nyOMLWMEBKg9w== Date: Thu, 19 Jun 2025 02:42:14 +0200 From: Alejandro Colomar To: linux-man@vger.kernel.org Cc: musl@lists.openwall.com, libc-alpha@sourceware.org, Paul Eggert , Bruno Haible , bug-gnulib@gnu.org Subject: malloc.3: Clarify realloc(3) standards conformance Message-ID: MIME-Version: 1.0 Content-Disposition: inline X-Spam-Status: No, score=-9.3 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libc-alpha-bounces~patchwork=sourceware.org@sourceware.org Hi! I've applied a patch to document the conformance of realloc(3) and reallocarray(3). See below, both the patch, and the formatted changes. BTW, Paul, Bruno, does gnulib also wrap reallocarray(3)? If not, it should. Have a lovely day! Alex --- commit 7279622113349f32428fa14467ba2aa9ef090394 Author: Alejandro Colomar Date: Thu Jun 19 02:27:48 2025 +0200 man/man3/malloc.3: VERSIONS, STANDARDS: Clarify conformance of realloc{,array}(3) Signed-off-by: Alejandro Colomar diff --git a/man/man3/malloc.3 b/man/man3/malloc.3 index 9cdfa6b58..bd6cc161f 100644 --- a/man/man3/malloc.3 +++ b/man/man3/malloc.3 @@ -241,6 +241,37 @@ .SH ATTRIBUTES .BR realloc () T} Thread safety MT-Safe .TE +.SH VERSIONS +The behavior of +.I realloc(p,\~0) +in glibc doesn't conform to any of +C99, +C11, +POSIX.1-2001, +POSIX.1-2008, +POSIX.1-2017, +or POSIX.1-2024. +The C17 specification was changed to make it conforming, +but that specification was broken +\[em]it is impossible to write code that works portably\[em], +and C23 changed it again to make this undefined behavior, +acknowledging that the C17 specification was broad enough that +undefined behavior wasn't worse than that. +The POSIX.1-2024 specification is good, +and ideally the ISO C standard should embrace something similar, +but glibc does not conform to it. +.P +musl libc conforms to all versions of ISO C and POSIX.1. +.P +gnulib provides the +.I realloc-posix +module, +which provides a wrapper +.BR realloc () +that conforms to POSIX.1-2024. +.P +.BR reallocarray () +suffers the same issues in glibc. .SH STANDARDS .TP .BR malloc () @@ -250,10 +281,10 @@ .SH STANDARDS .BR calloc () .TQ .BR realloc () -C11, POSIX.1-2008. +C23, POSIX.1-2024. .TP .BR reallocarray () -None. +POSIX.1-2024. .SH HISTORY .TP .BR malloc () $ MANWIDTH=72 diffman-git HEAD --- HEAD^:man/man3/malloc.3 +++ HEAD:man/man3/malloc.3 @@ -126,15 +126,34 @@ │ realloc() │ │ │ └────────────────────────────────────┴───────────────┴─────────┘ +VERSIONS + The behavior of realloc(p, 0) in glibc doesn’t conform to any of + C99, C11, POSIX.1‐2001, POSIX.1‐2008, POSIX.1‐2017, or + POSIX.1‐2024. The C17 specification was changed to make it con‐ + forming, but that specification was broken —it is impossible to + write code that works portably—, and C23 changed it again to + make this undefined behavior, acknowledging that the C17 speci‐ + fication was broad enough that undefined behavior wasn’t worse + than that. The POSIX.1‐2024 specification is good, and ideally + the ISO C standard should embrace something similar, but glibc + does not conform to it. + + musl libc conforms to all versions of ISO C and POSIX.1. + + gnulib provides the realloc‐posix module, which provides a wrap‐ + per realloc() that conforms to POSIX.1‐2024. + + reallocarray() suffers the same issues in glibc. + STANDARDS malloc() free() calloc() realloc() - C11, POSIX.1‐2008. + C23, POSIX.1‐2024. reallocarray() - None. + POSIX.1‐2024. HISTORY malloc()