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

Re: Is it woth to have SVN_REVNUM_T_FMT?

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-04-06 10:19:04 CEST

C.A.T.Magic wrote:

> Branko Čibej wrote:
>> C.A.T.Magic wrote:
>>> Branko Cibej wrote:
>>>> -- Always use %ld (or %lu), and cast the values. Not good, because
>>>> we then truncate 64-bit values on 32-bit platforms. Unfortunately
>>>> there is no portable format string for 64-bit integers.
>>>> -- Define our own formats (e.g., %R for revision numbers) and write
>>>> our own printf format scanner that converts them to the defined
>>>> macros (urgh!)
>>> why doesn't
>>> apr_file_printf
>>> do this by itself?
>>> this way you could get rid of all these weird
>>> apr_file_printf(out, "%" APR_SIZE_T_FMT " bytes were read\n",
>>> total_bytes);
>>> constructs at the same time.
>>> I think APR could even be modified for this without creating
>>> incompatibilities with existing applications,
>>> because "%" APR_SIZE_T_FMT " bytes" would simply resolve to
>>> something like "%Z bytes" for all applications.
>>> but i don't know the design decisions for this in APR.
>> These could of course be added to APR, and that would be the nicest
>> solution -- *if* we use APR's vformatter functions exclusively. But
>> that's something we can't require from all clients.
> maybe the modified APR (or svn) vformatter could support BOTH,

Therewas obviously never any doubt about that; we can't change APR's
printf rewrite, we can only extend it.

> old AND newstyle formats at the same time, this way other
> applications can continue to use the existing format names,
> e.g. %ld %s AND new ones like %Az (size) %Ai (int32)
> %AI (int64) %As (string) etc
> (assuming the letter 'A' is unused yet - i didn't check that)
> if apr doesnt want to support such a modified function it should
> still be possible to write an svn specific one that performas
> 'search&replace' of its %A specific flags into the APR_SIZE_T_FMT
> macros.

That's the solution I like the least, because ut's not just a simple
search and replace -- at least not in the standard printf syntax -- and
it slows things down tremendously. On the other hand, none of the
printfs is in a performance-critial part of the code.

> on the other hand all this feels like reinventing another wheel
> (printf) - i wonder how other applications solve this
> gettext+platform_specific_format problem. I'm also not sure about
> if a handwritten printf will be slower than the system (libc?)
> printf. - btw, since this is opensource, is it possible to
> 'grab' the standard libc printf and modify it for this?

Um. There _is_ no "standard" printf. If you're thinking about the one in
glibc, that's a no-no because of GPL -- and it's likely to be slower
than APR's version, because IIRC it's designed to be extensible.

Oh, well...

Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 6 10:19:30 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.