bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Roland McGrath
Subject: Re: [PATCH 2/5] obstack tidy part 2
Date: Thu, 30 Oct 2014 12:51:11 -0700 (PDT)

> 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.

> b) Don't roll our own slow memcpy in _obstack_newchunk.

Good change.

> c) Rename obstack_free to _obstack_free.  This makes the naming
>    consistent with other obstack functions and obviates the need for
>    __obstack_free.  Ancient obstack.c defined both obstack_free and
>    _obstack_free.  We continue to do that for _LIBC via an alias.
> d) Miscellaneous macro fixes.  The expression used to test for gcc-2.8
>    is clever, but nowadays gcc warns on undefined macros.  You'll get
>    an undefined macro warning if simulating an old gcc with -U__GNUC__
>    -U__GNUC_MINOR__ -D__GNUC__=1.

These seem OK to me.

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]