From patchwork Thu Oct 30 23:54:23 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alan Modra X-Patchwork-Id: 405148 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3A13C140080 for ; Fri, 31 Oct 2014 10:54:40 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; q=dns; s=default; b=Xkvy zxkj50KLWHUZ+ruMIqfAz59qgFMjoT0k0ejGh1cAUMMzmnLyWGPqyLSg2RqJmqWY cJ9A4LgIwkYkhXTgCh6WeLdgwISu+nF6XMUSEtRZ+LUg+AXDyAatFQhrfHlWhC7I I1S8KwwJrQ2WhCDhj0LFXqEmyInva4/QgL3etgc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; s=default; bh=MKOZUM0J+8 fO9kttpHeLUsmRKAE=; b=mQH1Ip5Aqapxg7G0vkWsmJqQiYh+PewJ85b5Hr3yIA TsMl7Y9c2f+GZvq7kZJUFiGr4Ir1S6ncpC9QvkVBGHRC0II8OvHtl29cf7ZjLBSX aOfvrhM+YyuIrUL0LUxan3GtS7P13F82FyhI7Wdt/Zzm/bBPnzHtUd+pAaGSA+kQ o= Received: (qmail 10899 invoked by alias); 30 Oct 2014 23:54:34 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 10890 invoked by uid 89); 30 Oct 2014 23:54:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pd0-f174.google.com X-Received: by 10.70.22.195 with SMTP id g3mr20563988pdf.37.1414713271393; Thu, 30 Oct 2014 16:54:31 -0700 (PDT) Date: Fri, 31 Oct 2014 10:24:23 +1030 From: Alan Modra To: Roland McGrath Cc: libc-alpha@sourceware.org, bug-gnulib@gnu.org Subject: Re: [PATCH 2/5] obstack tidy part 2 Message-ID: <20141030235423.GS4267@bubble.grove.modra.org> References: <20141029033222.GK4267@bubble.grove.modra.org> <20141030195111.D1DC42C3B15@topped-with-meat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20141030195111.D1DC42C3B15@topped-with-meat.com> User-Agent: Mutt/1.5.23 (2014-03-12) On Thu, Oct 30, 2014 at 12:51:11PM -0700, Roland McGrath wrote: > > a) Don't be concerned about "not polluting the namespace with stddef.h > > symbols" in obstack.h, since gnulib string.h includes stddef.h > > anyway, and it seems unlikely that anyone would care. > > libc is where this sort of constraint is most likely to be important. I > doubt gnulib users care. Since obstack.h is not standard, we are free to > decide we don't care for libc either. But it is not something to be done > lightly. If this change doesn't actually enable anything else you're > doing, please leave it for later as a separate individual item. stddef.h is needed for size_t, used in the next patch of the series. Hmm, I see most of glibc's public headers that require size_t do so using "#define __need_size_t". Would the following be acceptable? #define __need_ptrdiff_t #define __need_size_t #include "stddef.h" Continuing to use PTR_INT_TYPE and inventing another for size_t rather than using the standard types just seems so 1980 style. > You didn't report what testing you did for the libc build, which is > mandatory for approval. In particular, we have 'make check-abi' to be > concerned with, which is not something relevant to gnulib. I built both x86_64-linux and i686-linux, and ran "make check". The cover letter noted that the abilist files need updating for the abi check to pass. Both builds showed the following diff, with the expected obstack symbols plus another apparently due to building with a non-standard prefix. I also looked at exported obstack symbols for various other non-standard builds, and checked that __GI__obstack_newchunk matched the proper _obstack_newchunk (I had it wrong at one stage). --- ../sysdeps/unix/sysv/linux/x86_64/64/libc.abilist 2014-07-02 13:52:44.682722675 +0930 +++ /home/alan/build/glibc/libc.symlist 2014-10-27 16:27:51.205030088 +1030 @@ -519 +519 @@ GLIBC_2.2.5 - _nl_default_dirname D 0x12 + _nl_default_dirname D 0x1c @@ -1856,0 +1857,8 @@ GLIBC_2.2.6 +GLIBC_2.21 + GLIBC_2.21 A + _obstack_allocated_p F + _obstack_begin F + _obstack_begin_1 F + _obstack_free F + _obstack_memory_used F + _obstack_newchunk F