From patchwork Thu Jun 19 13:57:47 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Alejandro Colomar X-Patchwork-Id: 114740 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 12C5C381C13B for ; Thu, 19 Jun 2025 13:58:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 12C5C381C13B 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=Ogl3yQXt X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from nyc.source.kernel.org (nyc.source.kernel.org [IPv6:2604:1380:45d1:ec00::3]) by sourceware.org (Postfix) with ESMTPS id 7D68E3882016 for ; Thu, 19 Jun 2025 13:57:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7D68E3882016 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 7D68E3882016 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2604:1380:45d1:ec00::3 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1750341476; cv=none; b=EWamlWHP0FxzfcE5bgOdq3pZTcewc2axKNzaMnzZisb5h9tdrCwvagjHKOEpc/M79Wpc3dnSfbd9gnFPeCioXUWFkJLrHEphgeh5APcXRDOgNMlPK5JVTF3+awI1YNHU343PRldS948rQ9rKoQ2xCn7iyVNpzcc9Wvxccg51lYI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1750341476; c=relaxed/simple; bh=qAC2VBHs914MAMmFc1xo3TlaVrYN+I+6bJh/wLkz/C4=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=AVBJe0RaRBbIxcDZDre6inqq5LjU3SRQ//vwbJVi3d649BdkgVd1m9/CH/aE9y1CPjjdrZ9c9Iwl5Uyd450TwlGZ4xb1IjzHihCNMsye628whC9KGOjmgN8KvENLNIXZapUPaqCNdDCaHYgObjydwvWyGpZUFS4tUW9hRNWs/N8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7D68E3882016 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 185C3A545E3; Thu, 19 Jun 2025 13:57:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DED51C4CEEA; Thu, 19 Jun 2025 13:57:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1750341475; bh=qAC2VBHs914MAMmFc1xo3TlaVrYN+I+6bJh/wLkz/C4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Ogl3yQXtHVCaJECXTxR2Zb7Qn8gl5mUaR8j2wYvo0YCfvzh3pJjQ4l20e5FTI1+2k ha4ebkC1G0sFa+z1zO47q+4cThJz0d21O1jSMKve7xiCuP7ExzvmZl4ojnwnlaRxeP 4wzikdZqLjvrmKxY9YrVYG5x3dX73d0DX3TrNTnCQ85tDQTnpMqrqNxakq2HM0iizB DI70ToWkq7ZMGb04GBgapNrYld/xdfQJnk8qVUkrPLOiCy/+3JL3E7G6eQh/1D7jq1 iR3iIEK+rUpcojVBe4lR60bzqpLGqs5StH11HqQj0weNL4EAu4FGT94X7RzzoZmEmr dq9sIl0YjlPUg== Date: Thu, 19 Jun 2025 15:57:47 +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: [v2] malloc.3: Clarify realloc(3) standards conformance Message-ID: <3cx3oylv6hid2eunibcre7c5oqncuxkrk25x2plme2fqzmdpsf@sh7tmopzzgd5> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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, Here's a revision of this change, addressing some concerns. I'm only showing the formatted changes, since the patch itself is unimportant. Have a lovely day! Alex --- $ MANWIDTH=72 diffman-git HEAD --- HEAD^:man/man3/malloc.3 +++ HEAD:man/man3/malloc.3 @@ -126,15 +126,32 @@ │ 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. + + 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() @@ -214,6 +231,22 @@ POSIX and the C standard do not allow replacement of malloc(), free(), calloc(), and realloc(). +BUGS + Programmers would naturally expect that realloc(p, size) is con‐ + sistent with free(p) and malloc(size). This is not explicitly + required by POSIX.1‐2024 or C11, but all conforming implementa‐ + tions are consistent with that. + + The glibc implementation of realloc() is not consistent with + that, and as a consequence, it is dangerous to call + realloc(p, 0) in glibc. + + A trivial workaround for glibc is calling it as + realloc(p, size?size:1). + + The workaround for reallocarray() in glibc —which shares the + same bug— would be reallocarray(p, n?n:1, size?size:1). + EXAMPLES #include #include