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
