Peter N. Lundblad wrote:
>Hi,
>
>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
>we support? Are you expecting to change it to at least 64 bits?
>
>
Yes, it is, and no, I'm not. I can't imagine a reasonable system which,
in the foreseeable future, would have to support more than 4 billion
distinct revisions (as opposed to transactions, of which we can have
many more).
>>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.
>
>
Good. So we can use Greg's suggestion for those, and forget about the rest.
>>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.
>
>
Very much so. The most we could do is use C99 types and format
constante, but of course we're not in a position to require a C99 compiler.
>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.
>
>
Good. Let's ditch SVN_REVNUM_T_FMT then, and rplace all instances with
%ld. GCC will warn if somebody uses the wrong format, anyway.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 10 20:16:42 2004