From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) by sourceware.org (Postfix) with ESMTPS id 2F044384A01E for ; Tue, 19 Jan 2021 01:08:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2F044384A01E Received: by mail-qk1-x730.google.com with SMTP id 143so20426365qke.10 for ; Mon, 18 Jan 2021 17:08: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:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jMBxilhYzjUy+9eI+1A2OBpiS6MPbT4jozfYTJHNp3Y=; b=ZyGgyTxtsWVVqC1k05P9dBHgAyc7RWV4Aix6QqiQMoEz9hkBFlWz/wMrvHJqsEROLO 55R/prgKY+hcQ2L6TliX90OL+RW03hLBXBsOzEfSF/HrxKYLmryFEO/K1XlTIxhx7+g2 9Pqljy/l8yk7a8/Ze6XgiVF1tRnoxQdBJdD3w+VRboHGrlpi7oiLR45nvKnUPjRLe5po yG3QGxV2fC2gz8WPDs0x4AbfZsB1EPXV+Ejy69/vNiQq9vxyVMUo6jtRTCKLMaW0u+1r O9xK/6mq9xsfduU/qIuXhddhbkr64mMZP2otnFhOAJLXoFNau3rExhpEbAqcX3zSf/eM Sk0A== X-Gm-Message-State: AOAM533VG69lB+86j2Wtinv/yg5QbIQz0gWmtF+9Nl3x/OoEqsgf5Csw hcThFoYInF3VIK+PvKFOFG8xMGfFu7w= X-Google-Smtp-Source: ABdhPJxipKRYezrnej8AQigQ/ifnLsUvsi+6vWtHXaFftbLgmKC9gKqixRnCRUCv5pFbgJr0mThnZg== X-Received: by 2002:ae9:f402:: with SMTP id y2mr2204470qkl.356.1611018517831; Mon, 18 Jan 2021 17:08:37 -0800 (PST) Received: from [192.168.0.41] (184-96-239-30.hlrn.qwest.net. [184.96.239.30]) by smtp.gmail.com with ESMTPSA id m13sm11214796qtu.93.2021.01.18.17.08.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Jan 2021 17:08:37 -0800 (PST) Subject: Re: [PATCH] add support for -Wmismatched-dealloc To: Florian Weimer , Martin Sebor via Libc-alpha , David Malcolm Cc: Joseph Myers References: <74efece7-9a4b-83ee-7fdd-475c0d514378@gmail.com> <758e723b-67cf-a211-7bc2-2ccd3fc744e5@gmail.com> <2555516b-4583-21fc-e844-fd44619488cd@gmail.com> <655918b2-16c6-74b1-6a49-505a7607007f@gmail.com> <87mtxok7ob.fsf@oldenburg2.str.redhat.com> <0aae9006-6001-8fc8-ad6d-c8e3ee60f82c@gmail.com> <87turwiqqw.fsf@oldenburg2.str.redhat.com> <87czybsuoe.fsf@oldenburg2.str.redhat.com> <87sg76led0.fsf@oldenburg2.str.redhat.com> From: Martin Sebor Message-ID: <682f022e-929b-9e90-e312-75cef8e47496@gmail.com> Date: Mon, 18 Jan 2021 18:08:35 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <87sg76led0.fsf@oldenburg2.str.redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, 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-List-Received-Date: Tue, 19 Jan 2021 01:08:39 -0000 David, now that you've committed the analyzer support for the extended attribute malloc, can you please comment on Florian's concern about using it to annotate realpath() as in the patch below? https://sourceware.org/pipermail/libc-alpha/2021-January/121527.html (I tested how it interacts with -Wmismatched-dealloc but I haven't yet had a chance to see how the annotations might interact with the analyzer warnings.) Thanks Martin On 1/12/21 1:59 AM, Florian Weimer wrote: > * Martin Sebor via Libc-alpha: > >>> realpath only returns a pointer to the heap if RESOLVED is null, so >>> the annotation is wrong here. > >> This is intentional. When realpath() returns the last argument >> (when it's nonnull) passing the returned pointer to free will not >> be diagnosed but passing it to some other deallocator not associated >> with the function will be. That means for example that passing >> a pointer allocated by C++ operator new() to realpath() and then >> deleting the pointer returned from the function as opposed to >> the argument will trigger a false positive. I decided this was >> an okay trade-off because unless the function allocates memory >> I expect the returned pointer to be ignored (similarly to how >> the pointer returned from memcpy is ignored). If you don't like >> the odds I can remove the attribute from the function until we >> have one that captures this conditional return value (I'd like >> to add one in GCC 12). > > Maybe David can comment on how this interacts with his static analyzer > work. In all other cases, the attribute means that the pointer needs to > be freed to avoid a resource leak. If we suddenly apply it pointers > which can only conditionally be freed, that reduces the value of those > annotations, I think. > > Thanks, > Florian >