[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Observations relating to r15828.

From: Jonathan Gilbert <o2w9gs702_at_sneakemail.com>
Date: 2005-08-19 21:37:00 CEST

At 06:48 PM 19/08/2005 +0100, Philip Martin wrote:
>Well, I haven't done much Subversion coding recently, but working on
>r15828 leads me to make the following observations:
[snip]
>2. I18N
>
> Using _("foo %s bar") defeats gcc's printf format string checking,
> if I insert '#define _(X) X' it starts working. Is there some
> magic way to configure/build so that all the formats get checked?
[snip]

One approach would be to add an attribute to the declaration of '_',
turning it into function:

char *_(const char *msgid) __attribute__((__format_arg__(1),
__always_inline__))
{
  return libintl_gettext(msgid);
}

This tells GCC that when '_' is passed as a format parameter to a
printf-like function, the argument to '_' should be used for type-checking
the arguments.

Another alternative, if '_' cannot be changed, would be to change:

printf(_("foo %s bar"), arg);

...into:

gtprintf("foo %s bar", arg);

...and then define gtprintf as:

int gtprintf(char *format, ...) __attribute__((__format__(__printf__, 1,
2), __always_inline__))
{
  va_list ap;
  int ret;

  va_start(ap, format);
  ret = vprintf(_(format), ap);
  va_end(ap);

  return ret;
}

For functions like these, I can't think of any reason not to always inline
the function, regardless of the optimization level. Perhaps there is such a
reason, though, in which case the __always_inline__ attribute would simply
be left off.

I don't really know that much about gettext or GCC attributes, I just
vaguely remembered there was something like this and looked it up in "info
gcc" :-)

Jonathan Gilbert

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 19 20:35:57 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.