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