From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id 5E1E8385800D for ; Tue, 15 Dec 2020 01:01:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5E1E8385800D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=joseph_myers@mentor.com IronPort-SDR: 1BnuLwPMQ2Wsd79Wb1TV4B9EFpgilDsne5nBmENBVRYuYQvmEvEVCmUw7Mn2LolRtBit4HJSBo mUCLknjv1CippHl1p34E87bpTAhZcRQOvjoSHCQ/OMlFbFadgCiMrBP1tNtALyTmgwSEtlPA8w y/JhCOGDQXH0vvecmWQCDt/BiDctH1H97bsohyOK26s8WNV5kvteTsHcOfi/sV5CRtQJEmF0hP BMdY2Xc/I8QWSvoPsc47ZHj1zfgI8CGVcpt1OG2c5iFKEKNtlFwlCj1jur3EiIelamVPBgog/1 Rl4= X-IronPort-AV: E=Sophos;i="5.78,420,1599552000"; d="scan'208";a="58445444" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa1.mentor.iphmx.com with ESMTP; 14 Dec 2020 17:01:58 -0800 IronPort-SDR: pqfLjG0jrer3iCQN3ux7vSJ3MEKBthO4uXSxa9dSrC+2GJHVpSqhOJcPbI+UorlEJo4hWBgxUK 7Y6idQo+uumX8Ep2WQN2DAWXMbgd4qlkadenhjbj8YbjaTz9ipVyWOF2K6E28R3NY/LmE2n4Iu pqcY5GIvHsSxHoea+lThCGM5DTBShHqXadkAdGY3TNYJNaN03E8WO5S6xgCs1MGOqJRh7GAF87 ovyYKxJWKN4ot66P/JsG+Z+KdvQSmSs65qRx0iP1/pFfM3vHJHJ9q931bafGhMF64ef22s6rKN 5Ds= Date: Tue, 15 Dec 2020 01:01:53 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Martin Sebor CC: Florian Weimer , GNU C Library Subject: Re: [PATCH] add support for -Wmismatched-dealloc In-Reply-To: <758e723b-67cf-a211-7bc2-2ccd3fc744e5@gmail.com> Message-ID: References: <74efece7-9a4b-83ee-7fdd-475c0d514378@gmail.com> <758e723b-67cf-a211-7bc2-2ccd3fc744e5@gmail.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-03.mgc.mentorg.com (139.181.222.3) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3124.5 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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, 15 Dec 2020 01:02:00 -0000 On Mon, 14 Dec 2020, Martin Sebor via Libc-alpha wrote: > > I spent some time working around this but in the end it turned out > > to be too convoluted so I decided to make the attribute a little > > smarter.  Instead of associating all allocation functions with all > > deallocation functions (such as fdopen, fopen, fopen64, etc. with > > fclose, freopen, and freopen64) I changed it so that an allocator > > only needs to be associated with a single deallocator (a reallocator > > also needs to be associated with itself).  That makes things quite > > a bit simpler. [...] > The GCC patches have now been committed and the dependency resolved. I've looked at the attribute documentation now in GCC, but I'm afraid I'm unable to understand from that documentation why the proposed glibc patch constitutes a valid way of specifying that, for example, it's valid to use freopen as a deallocator for FILE pointers opened by functions whose attribute only mentions fclose. Unless there's something I'm missing in the documentation or a separate documentation patch that's not yet committed, I think more work is needed on the GCC documentation to make clear the semantics the glibc patch is asserting for valid combinations of allocators and deallocators, so that those semantics can be reviewed for correctness. -- Joseph S. Myers joseph@codesourcery.com