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

Re: replacing SVN_REVNUM_T_FMT for translation

From: Peter N. Lundblad <lundblad_at_softhome.net>
Date: 2004-05-10 10:03:32 CEST


On Sun, 9 May 2004, Greg Hudson wrote:

> On Sun, 2004-05-09 at 16:05, Erik Huelsmann wrote:
> > 2) Replace the SVN_REVNUM_T_FMT'- with their real value; thus hardcoding the
> > format into about 200 strings.
> I'm not terribly opposed to this, since we control the definition of

What are the chances that long will not do for a revision number for the
forseable future? Isn't long at least 32 bits, at least on all platforms
support? Are you expecting to change it to at least 64 bits?

> svn_revnum_t. But if we go this route, have we determined what we will
> do about APR_SIZE_T_FMT and APR_OFF_T_FMT, where we don't know or
> control the value? I suppose it's possible that we never use them in
> localizable strings, or that we do so rarely enough that we could just
> use "%s" with an argument of apr_psprintf(pool, "%" APR_OFF_T_FMT, blah)
> with no wrapper.
I grepped for APR_SIZE_T_FMT and APR_OFF_T_FMT. They are used in some
error messages (less than ten) and in other places that aren't
localizable, so it seems your assumption holds true.

> Attractive as some variant of (3) sounds as a solution to all of life's
> problems, I think it will get us into trouble because no one else does

Just to see how others do it, I checked the GNU gettext manual. It has
special-cased the C99 formatting macros (PRId32 etc.). They get something
like %<PRId32> and that is translated back at runtime to the right
formatting specifier. For "your own similar macros", they recommend
sprintf and a separate buffer.

Ofcourse, teaching gettext about our _FMT macros is out of question.

So, since we don't really like svn_revnum_to_cstring, couldn't we just use
%ld as Branko suggested. If we, for some reason someday, need to change
the data type (to 64 bits), it isn't more than 200 text messages to
update. It is an evening's work, not more.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 10 09:54:04 2004

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.