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.133.124]) by sourceware.org (Postfix) with ESMTPS id 36C883858C50 for ; Fri, 17 Mar 2023 22:11:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 36C883858C50 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=1679091060; 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=fC8/mui4sefZTGP3GiF05R6GcIR37vVlX3Jy4YeZ4Rg=; b=fKZGOuTZH5qIBr0CCv9Lh7KfI1pwM5Sq37PuuacXVDbmj0fhS4Y335y8Q62BAQ+5XmCDfu 6z3fItnwTALvwnp1JskLEbfU9XBf+x0kZ+UzH4UX17EmlKi+rOYeCgF9T84ONhz6c07lTz IMEHoyefuXE84l+GdygnLEgazbU6SoQ= 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-122-3zz7uxRtNa65dPqFCdlexw-1; Fri, 17 Mar 2023 18:10:59 -0400 X-MC-Unique: 3zz7uxRtNa65dPqFCdlexw-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 3ED9196DC81 for ; Fri, 17 Mar 2023 22:10:59 +0000 (UTC) Received: from greed.delorie.com (unknown [10.22.9.230]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2C1C140D1C7; Fri, 17 Mar 2023 22:10:59 +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 32HMAwD13649827; Fri, 17 Mar 2023 18:10:58 -0400 From: DJ Delorie To: Florian Weimer Cc: libc-alpha@sourceware.org Subject: Re: [patch v2] aligned_alloc: conform to C17 In-Reply-To: <87mt4bt4uh.fsf@oldenburg.str.redhat.com> Date: Fri, 17 Mar 2023 18:10:58 -0400 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Florian Weimer writes: > Why do we need to export the __libc_aligned_alloc symbol? That doesn't > seem to be right. We should simply change the behavior of the existing > aligned_alloc symbol. I did it only because memalign has a __libc_memalign symbol. The old symbol used to be a weak alias for __libc_memalign, so to change it, we need a separate function - which would thus be __libc_aligned_alloc, so that aligned_alloc() can continue to be a weak function. > If you do not want to change behavior for existing binaries (why?), I'm going on the premise that aligned_alloc() is new to C11 and was always documented to fail in the way I'm making it now fail (although there are other "documented to fail" cases we're not implementing). Thus there is no need to support a pre-C11 functionality.