public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Roland McGrath <roland@hack.frob.com>
To: Alan Modra <amodra@gmail.com>
Cc: libc-alpha@sourceware.org, bug-gnulib@gnu.org
Subject: Re: [PATCH 2/5] obstack tidy part 2
Date: Thu, 30 Oct 2014 19:51:00 -0000	[thread overview]
Message-ID: <20141030195111.D1DC42C3B15@topped-with-meat.com> (raw)
In-Reply-To: Alan Modra's message of  Wednesday, 29 October 2014 14:02:22 +1030 <20141029033222.GK4267@bubble.grove.modra.org>

> 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	other threads:[~2014-10-30 19:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1414461460.git.amodra@gmail.com>
2014-10-29  3:32 ` [PATCH 4/5] 64-bit obstack support, " Alan Modra
2014-10-29  3:32 ` [PATCH 1/5] obstack tidy part 1 Alan Modra
2014-10-30 19:43   ` Roland McGrath
2014-10-29  3:32 ` [PATCH 3/5] 64-bit obstack support, " Alan Modra
2014-10-30 19:52   ` Roland McGrath
2014-10-31  0:38     ` Alan Modra
2014-10-29  3:32 ` [PATCH 2/5] obstack tidy part 2 Alan Modra
2014-10-30 19:51   ` Roland McGrath [this message]
2014-10-30 23:54     ` Alan Modra
2014-10-29  3:33 ` [PATCH 5/5] 64-bit obstack support, part 3 Alan Modra
2014-10-29  3:35 ` [PATCH] 64-bit obstack support Alan Modra
2014-10-29 18:34   ` Joseph S. Myers
2014-10-30  1:53     ` Alan Modra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141030195111.D1DC42C3B15@topped-with-meat.com \
    --to=roland@hack.frob.com \
    --cc=amodra@gmail.com \
    --cc=bug-gnulib@gnu.org \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).