Re: [PATCH 2/5] obstack tidy part 2

[Alan Modra <amodra@gmail.com>]

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