Hi, Erik,
On Sun, 9 May 2004, Erik Huelsmann wrote:
> Until now three methods have been identified to achieve this goal:
>
> 1) Use (a) a macro or (b) a function to convert the svn_revnum_t to a
> string, replacing the format within the string with the "%s" string format.
>
> 2) Replace the SVN_REVNUM_T_FMT'- with their real value; thus hardcoding the
> format into about 200 strings.
>
> 3) Code SVN_REVNUM_T_FMT with a special identifier ("%R"?) and use a
> translator function which understands this (these?) identifiers and
> translates them into their printf; this can be done by (a) overriding
> apr_psprintf or by (b) pre-translating the string and passing that string to
> APR.
>
Would 3 a) mean to rewrite apr_psprintf, or is it customizable in any way?
> Understandibly Branko objects due to the large scale on which the somewhat
> hacky solution of 1a and 1b has to be applied. Presumably he'd also object
> to solution 3b.
>
I don't see 1 as hacky, since that's what you'd do for more complicated
data types in C (i.e. structs or enums (if you want the string value)).
I'd rather call it somewhat overkill to use a function to format a long...
> I'd prefer 3a because of its elegance, but can see how its complexity isn't
> desirable. I'd rather not resort to 2 even though I understand the
> unlikeliness of changing the data type for svn_revnum_t.
>
For 3 a), we also need to check what the gettext utils say about a new
type specifier in the c-format check. It checks that the format specifiers
in the message id and the translation are consistent with each other. This
is very useful, since it is quite easy to switch the order of an %d and an
%s by mistake. We don't want this to happen very often...
I agree that 3a might be a good solution with the reservations above. Also
ote that we seem to only use a small subset of the printf format
specifiers, so reinventing the wheel may not be that hard this time if
that's necessary. Do we use more than %s, %d, %ld, width specifiers and
maybe a minus for left-justification?
Regards,
//PPeter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 9 22:43:13 2004