From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DB019C432BE for ; Thu, 2 Sep 2021 01:23:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B21FB60200 for ; Thu, 2 Sep 2021 01:23:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232372AbhIBBYa convert rfc822-to-8bit (ORCPT ); Wed, 1 Sep 2021 21:24:30 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:59318 "EHLO zimbra.cs.ucla.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229606AbhIBBYa (ORCPT ); Wed, 1 Sep 2021 21:24:30 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 56289160144; Wed, 1 Sep 2021 18:23:32 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id qiMA3Z-7RiPJ; Wed, 1 Sep 2021 18:23:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9FF53160157; Wed, 1 Sep 2021 18:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Fb867ZHxAFiQ; Wed, 1 Sep 2021 18:23:31 -0700 (PDT) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 728C2160144; Wed, 1 Sep 2021 18:23:31 -0700 (PDT) To: mtk.manpages@gmail.com Cc: Florian Weimer , "libc-alpha@sourceware.org" , linux-man , "Alejandro Colomar (man-pages)" References: <87lf4im6sf.fsf@oldenburg.str.redhat.com> <03f3b96f-1dd4-e9cb-2f24-7fc8ae7252bc@cs.ucla.edu> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: Adding a realloc() usage note to the malloc(3) manual page Message-ID: Date: Wed, 1 Sep 2021 18:23:31 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-man@vger.kernel.org On 9/1/21 5:21 PM, Michael Kerrisk (man-pages) wrote: > Obviously, '*ptr' is invalid after a > successful realloc(). But why is 'ptr' invalid? The C standard says that once a program has freed a non-null pointer, the program cannot look at the pointer's value any more. It can't copy the value to another pointer, and it can't even test whether the value is null. A debugging implementation can trap any use of the pointer's value. This rule is not an issue for production uses of glibc realloc. However, it could at least in theory affect debugging implementations like gcc -fsanitize=address, because the rule can help catch bugs in programs. And I vaguely recall talk that a few non-glibc platforms (IBM i, perhaps?) enforce the rule.