From: Tom Tromey <tromey@redhat.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [patch 1/3] Make obconcat use stdarg
Date: Fri, 30 Apr 2010 18:38:00 -0000 [thread overview]
Message-ID: <m31vdwzsxy.fsf@fleche.redhat.com> (raw)
In-Reply-To: <20100430181605.GA19190@host0.dyn.jankratochvil.net> (Jan Kratochvil's message of "Fri, 30 Apr 2010 20:16:05 +0200")
>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
Jan> __attribute__ ((sentinel)) availability for gcc >= 4.0 I have copied from
Jan> <glib-2.0/glib/gmacros.h>. It roughly matches the GCC ChangeLog dates.
Jan> Still I find this patch as a code cleanup.
I agree.
Jan> +obconcat (struct obstack *obstackp, ...)
Jan> +{
Jan> + va_list ap;
Jan> + size_t len = 1;
Jan> + char *retval, *dest;
Jan> +
Jan> + va_start (ap, obstackp);
Jan> + for (;;)
Jan> + {
Jan> + const char *s = va_arg (ap, const char *);
Jan> +
Jan> + if (s == NULL)
Jan> + break;
Jan> + len += strlen (s);
Jan> + }
Jan> + va_end (ap);
I think it is better to just do the copying in a single loop.
Obstacks already handle growing objects well enough, there's no need to
work around this.
Personally I think this function would be better placed in util.c, but
that isn't a requirement for patch.
Tom
next prev parent reply other threads:[~2010-04-30 18:38 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-30 18:16 Jan Kratochvil
2010-04-30 18:38 ` Tom Tromey [this message]
2010-04-30 19:07 ` Jan Kratochvil
2010-04-30 19:09 ` Mark Kettenis
2010-04-30 22:18 ` `sentinel' gcc-3.x/OpenBSD compat. [Re: [patch 1/3] Make obconcat use stdarg] Jan Kratochvil
2010-05-01 0:10 ` Pedro Alves
2010-05-02 12:04 ` [patch] ATTR_* -> ATTRIBUTE_* unification [Re: `sentinel' gcc-3.x/OpenBSD compat.] Jan Kratochvil
2010-05-02 15:33 ` Pedro Alves
2010-05-02 21:37 ` Jan Kratochvil
2010-05-02 23:20 ` [patch] ATTR_NORETURN -> ATTRIBUTE_NORETURN unification [Re: [patch] ATTR_* -> ATTRIBUTE_* unification] Jan Kratochvil
2010-05-02 23:42 ` Pedro Alves
2010-05-02 23:53 ` Jan Kratochvil
2010-05-03 7:18 ` Pierre Muller
2010-05-03 7:44 ` Jan Kratochvil
2010-05-04 6:34 ` Pierre Muller
2010-05-04 15:28 ` Joel Brobecker
[not found] ` <6652.26431233368$1272871093@news.gmane.org>
2010-05-03 18:15 ` Tom Tromey
2010-05-01 6:07 ` `sentinel' gcc-3.x/OpenBSD compat. [Re: [patch 1/3] Make obconcat use stdarg] Eli Zaretskii
2010-05-02 6:49 ` Jan Kratochvil
2010-05-01 8:53 ` Mark Kettenis
2010-05-07 16:58 ` Jan Kratochvil
2010-05-07 22:34 ` Tom Tromey
2010-05-08 4:59 ` Jan Kratochvil
2010-05-02 7:52 ` [patch 1/3] Make obconcat use stdarg Jan Kratochvil
2010-05-03 18:25 ` Tom Tromey
2010-05-03 20:19 ` Mark Kettenis
2010-05-03 21:00 ` Pedro Alves
2010-05-04 21:03 ` Mark Kettenis
2010-05-07 14:31 ` Jan Kratochvil
2010-05-07 14:36 ` Pedro Alves
2010-05-07 14:44 ` Jan Kratochvil
2010-05-07 14:44 ` Mark Kettenis
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=m31vdwzsxy.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
/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