From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@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: Thu, 30 Oct 2014 23:54:00 -0000 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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141030195111.D1DC42C3B15@topped-with-meat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2014-10/txt/msg00780.txt.bz2 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. --- ../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 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). -- Alan Modra Australia Development Lab, IBM