From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 5DA393858D3C for ; Fri, 2 Dec 2022 19:16:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5DA393858D3C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1670008597; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=ps3FrJVnzbFC8gEfaLGsLtD/eT/QHr9+BXNCNoXF2F0=; b=OnThisWdrMw3ECL0nbBccFwmbZqr3TY09MF6bE5EouPNtv9kZgZAfOvhEcjGIhTprVLCpc 4t79DEl7x8U0u/GGgY7O4nzW5c8fL+8SlHv9DgxduScCXsvoKfXFIfISVntJC4NFMI7A3P K8AlJvQL7tNkzxANS27W7ExwSRKFsLw= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-391-k4uJuueKPlK2JkA0ycEXqg-1; Fri, 02 Dec 2022 14:16:35 -0500 X-MC-Unique: k4uJuueKPlK2JkA0ycEXqg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 42C3E3804508; Fri, 2 Dec 2022 19:16:35 +0000 (UTC) Received: from greed.delorie.com (unknown [10.22.8.183]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2F15740C845E; Fri, 2 Dec 2022 19:16:35 +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 2B2JGNng1109510; Fri, 2 Dec 2022 14:16:23 -0500 From: DJ Delorie To: Siddhesh Poyarekar Cc: sam@gentoo.org, libc-alpha@sourceware.org Subject: Re: [RFC] Supporting malloc_usable_size In-Reply-To: Date: Fri, 02 Dec 2022 14:16:23 -0500 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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 List-Id: Siddhesh Poyarekar writes: > On to the alternative question then; given that the interface has > minimal utility, unnecessarily exposes internal implementation caveats > and is prone to abuse, does it make sense to deprecate it? If not, does > it make sense to make the note in the man page stronger by, e.g. > removing the "without ill effects" and discourage its use for anything > other than diagnostics? I see no reason to deprecate this call, as long as it does what it's documented to do. Just because we think it's a bad API doesn't mean some other developer won't find it immensely useful in some way we haven't imagined. Existing notes: The value returned by malloc_usable_size() may be greater than the requested size of the allocation because of alignment and minimum size constraints. Although the excess bytes can be overwritten by the application without ill effects, this is not good programming practice: the number of excess bytes in an allocation depends on the underlying implementation. Suggested text:? The value returned by malloc_usable_size() may be greater than the requested size of the allocation because of various internal implementation details, none of which the programmer should rely on. This function is intended to only be used for diagnostics and statistics; writing to the excess memory without first calling realloc() to resize the allocation is not supported. The returned value is only valid at the time of the call; any other call to a malloc family API may invalidate it. I think this is as harsh as we should go, and I'm not opposed to removing any of the above if we think it oversteps the ABI bounds.