From: Robert Millan <rmh@aybabtu.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: [PATCH] switch from sprintf to asprintf and snprintf
Date: Wed, 20 Jan 2010 00:16:00 +0100 [thread overview]
Message-ID: <20100119231600.GK8599@thorin> (raw)
In-Reply-To: <20100119225648.GH5847@riva.ucam.org>
On Tue, Jan 19, 2010 at 10:56:48PM +0000, Colin Watson wrote:
> On Tue, Jan 19, 2010 at 11:29:14PM +0100, Robert Millan wrote:
> > On Sun, Jan 17, 2010 at 01:02:55PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> > > Robert Millan wrote:
> > > > On Fri, Jan 01, 2010 at 09:32:24AM +0000, Colin Watson wrote:
> > > >> On Tue, Dec 29, 2009 at 10:30:12AM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> > > >>> +char *EXPORT_FUNC(grub_asprintf) (const char *fmt, ...)
> > > >>> + __attribute__ ((format (printf, 1, 2)));
> > > >>
> > > >> It's very confusing that you've made grub_asprintf have a dramatically
> > > >> different interface from asprintf. Perhaps you could call this
> > > >> grub_xasprintf instead?
> > > >
> > > > Is it feasible to implement the same interface as asprintf instead?
> > >
> > > it's feasible but the only advantage it gives is the return value nobody
> > > uses anyway
> >
> > What about consistency with what programmers expect?
> >
> > If you don't want the return value, you can just discard it.
>
> asprintf is not really an advantageous interface to emulate. It
> requires tedious manual error handling and hardly anyone gets it right
> (GRUB didn't get it right across the board, before I converted it to
> xasprintf!), not to mention that error_code = function (&string, ...) is
> unpleasant to start with. xasprintf is a much nicer interface; simply
> returning the string is what most programmers *actually* expect unless
> they've already bent their brains around asprintf.
Meh, I guess I'm one of those programmers who bent their brains.
Ok, feel free to go with proposed interface as grub_xasprintf().
--
Robert Millan
"Be the change you want to see in the world" -- Gandhi
next prev parent reply other threads:[~2010-01-19 23:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-29 9:30 [PATCH] switch from sprintf to asprintf and snprintf Vladimir 'φ-coder/phcoder' Serbinenko
2010-01-01 9:32 ` Colin Watson
2010-01-01 11:52 ` Robert Millan
2010-01-01 12:01 ` Colin Watson
2010-01-17 12:02 ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-01-19 22:29 ` Robert Millan
2010-01-19 22:56 ` Colin Watson
2010-01-19 23:16 ` Robert Millan [this message]
2010-01-17 11:59 ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-01-01 11:51 ` Robert Millan
2010-01-17 12:02 ` Vladimir 'φ-coder/phcoder' Serbinenko
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=20100119231600.GK8599@thorin \
--to=rmh@aybabtu.com \
--cc=grub-devel@gnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.