From: Pedro Alves <pedro@codesourcery.com>
To: Tom Tromey <tromey@redhat.com>
Cc: gdb-patches@sourceware.org,
Werner Almesberger <werner@almesberger.net>,
Jon Beniston <jon@beniston.com>
Subject: Re: [PATCH] 32 bit-ism in lm32-tdep.c (and some sloppy macros)
Date: Mon, 14 Nov 2011 16:28:00 -0000 [thread overview]
Message-ID: <201111141627.57802.pedro@codesourcery.com> (raw)
In-Reply-To: <m3vcqmr7zf.fsf@fleche.redhat.com>
On Monday 14 November 2011 16:20:36, Tom Tromey wrote:
> >>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:
>
> Pedro> On Monday 14 November 2011 15:48:48, Tom Tromey wrote:
> >> I was a little surprised to find out we already use int16_t in gdb.
>
> Pedro> We pull stdint.h from gnulib.
>
> I was meaning to ask ... do we have a gnulib update policy?
I don't think we do. I think we've updated about twice only since
adding gnulib, and it was because there was something new in gnulib
that we needed. I've done it once.
> I wanted to pull in stdbool.h and start using bool in gdb; plus maybe
> some other bits so we can use O_CLOEXEC and friends (but only maybe --
> it isn't clear to me that gnulib is the best way to tackle this
> problem). Anyway, then I noticed that the existing files are not
> up-to-date against gnulib git.
>
> It seemed to me that updating now, just before a release, was maybe not
> the best time. Any thoughts?
Agreed. After release sounds best. Do you know if gnulib follows any sort
of stable release/period in their trunk? That is, is there any time that
is better for pulling current gnulib state that is better or worse
then others, in terms of pulling in gnulib bugs or works-in-progress?
--
Pedro Alves
next prev parent reply other threads:[~2011-11-14 16:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-11 23:38 Werner Almesberger
2011-11-14 15:49 ` Tom Tromey
2011-11-14 15:55 ` Jon Beniston
2011-11-14 15:58 ` Tom Tromey
2011-11-14 16:12 ` Pedro Alves
2011-11-14 16:21 ` Tom Tromey
2011-11-14 16:28 ` Pedro Alves [this message]
2011-11-14 16:41 ` Tom Tromey
2011-11-23 14:16 ` Mark Kettenis
2011-11-23 19:19 ` Mike Frysinger
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=201111141627.57802.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=jon@beniston.com \
--cc=tromey@redhat.com \
--cc=werner@almesberger.net \
/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