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 7B0BA3858D32 for ; Fri, 2 Dec 2022 05:28:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7B0BA3858D32 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=1669958930; 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=ImcAjnpIRTNrbW3Ocpnq4wR4W/TXEjKwaCGfx5kEnu0=; b=hvHMM4SDOTdnBRGDZYSgKCvcHRTD1sIAq+pmO2MOWJiy3KVYdlqIAyr3ZJ2ObpgGzRn/XM ue7Wz3kabdsCKoLIYtJ4ZLfVeDrtPuNDiY/4z64c0DLmFX0zCqrq4Dxs+ZgvYTfP3l8xti L3NusdrF7I8lFrqOw8WAqAm31GGt7no= 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-655-fCVTmRidNkur7yxnVRtvTg-1; Fri, 02 Dec 2022 00:28:48 -0500 X-MC-Unique: fCVTmRidNkur7yxnVRtvTg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6C7C2811E7A; Fri, 2 Dec 2022 05:28:48 +0000 (UTC) Received: from greed.delorie.com (unknown [10.22.8.183]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 439BE1402BDC; Fri, 2 Dec 2022 05:28:48 +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 2B25Sbpk1003506; Fri, 2 Dec 2022 00:28:37 -0500 From: DJ Delorie To: Sam James Cc: siddhesh@gotplt.org, libc-alpha@sourceware.org Subject: Re: [RFC] Supporting malloc_usable_size In-Reply-To: <8E77ABD5-E885-4239-B6E6-A956B49BD6AC@gentoo.org> Date: Fri, 02 Dec 2022 00:28:37 -0500 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.5 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: Sam James writes: > Right. It's still not clear to me if glibc is actually interested in supporting > the use case here. If it isn't, it should be stated clearly so it's clear > who is to blame when FORTIFY_SOURCE=3 complains. I don't think it's up to glibc to support a "use case" per se. The API does what is documented, no more, no less. As long as we function "correctly", the users can abuse that functionality all they want. My opinion is just that, when they do that, it's up to them to make sure their abuse plays well with other tools, like gcc and FORTIFY_SOURCE=3. Hence my focus on documentation. We can document what the APIs do. We can provide a tutorial that helps people understand how the APIs work together in a "best practices" way. We can list caveats that document whar be dragons. Beyond that, caveat programmer.