From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, PDS_RDNS_DYNAMIC_FP,RCVD_IN_DNSWL_MED,RDNS_DYNAMIC,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 0F0801F601 for ; Fri, 2 Dec 2022 04:43:31 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="gPtRKFKb"; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C555D3858C39 for ; Fri, 2 Dec 2022 04:43:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C555D3858C39 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1669956209; bh=uWyvhQvJYZvPb4VAgywYqFqPBVmhnTXWcAOH4745kwM=; h=To:Cc:Subject:In-Reply-To:Date:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=gPtRKFKbrrr6t1nQEElyMAx8wpoZuIcHNajQjPn/Ov4T+lamcH4aUWH1G6C2IJx5Y 16udKduJxyb1ziKJgGlmbvWTLw4+ULGiZmlGbkUN/rZlvxnuN5e3l4rtcijBMpTZTd G8Jdbf27zIao9EhLa0BA50fB3jT7yPIUFlLRQ4Ns= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id E6D373858D35 for ; Fri, 2 Dec 2022 04:43:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E6D373858D35 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-470-TH5-aHGxOfuUYbdeC7_dbw-1; Thu, 01 Dec 2022 23:43:09 -0500 X-MC-Unique: TH5-aHGxOfuUYbdeC7_dbw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 29B36886065; Fri, 2 Dec 2022 04:43:09 +0000 (UTC) Received: from greed.delorie.com (unknown [10.22.8.183]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 15DF8202279C; Fri, 2 Dec 2022 04:43:09 +0000 (UTC) Received: from greed.delorie.com.redhat.com (localhost [127.0.0.1]) by greed.delorie.com (8.15.2/8.15.2) with ESMTP id 2B24gvY5997634; Thu, 1 Dec 2022 23:42:57 -0500 To: Siddhesh Poyarekar Cc: libc-alpha@sourceware.org Subject: Re: [RFC] Supporting malloc_usable_size In-Reply-To: <20221124213258.305192-1-siddhesh@gotplt.org> Date: Thu, 01 Dec 2022 23:42:57 -0500 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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: , From: DJ Delorie via Libc-alpha Reply-To: DJ Delorie Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" Siddhesh Poyarekar writes: > At that time, I thought this use was to avoid reallocating[1] when You can't do an optimal realloc if you don't know what the usable size is, but once you know the optimal size, calling realloc() should be a valid way of telling the compiler what you're doing. We just need to ensure that our realloc() does the sane thing in such cases and I see no problem with users doing it. > that maybe providing a fast path for cases where the new > size was within the current chunk size was the solution to the problem > systemd was trying to solve with malloc_usable_size. I think a fast path check would be good for performance anyway, but let's not call it a solution, because it won't change the functionality, just the speed. > it is used as a way to query sizes of objects and hence eliminating > the need to pass their corresponding sizes. Since malloc_usable_size is nonstandard and intended for debugging, this is a bad programming practice (as noted in the man page). As such, I see no need to spend effort on it, either to block it or to optimize it. Caveat programmer. As long as the function returns the correct value, I have no desire to worry about it further ;-) > I have an idea to support this abuse and at the same time, satisfy the > compiler by giving it a hint of the new size. That's a lot of work to avoid a call to realloc(). And if they're calling into libc to get a record size, they already don't care about optimal performance. > The larger consequence of this patch though is that we further support > the usage of malloc_usable_size for cases beyond diagnostics. Do we > want to do that? To what extend do we support it *at all*, other than "it returns the right number at the time it was called" ? > If we do, should we also then make clear what kind of usage we support > as a library, say, in the manual? Our man page already says "The main use of this function is for debugging and introspection". The BSD manual says "The malloc_usable_size() function is not a mechanism for in-place realloc(); rather it is provided solely as a tool for introspection purposes." So clarifying the manual to be more in line with BSD is probably OK but anything further than that is IMHO an API change. We may want to add a caveat that the returned value is only valid until the next call to any malloc family function, though, although I don't see any way our code could make the usable size of an allocated chunk *smaller*. I don't think we've ever guaranteed that the heap metadata is constant. Maybe as a lark we could make 1% of the calls return an obviously wrong value? ;-)