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,
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.
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?
:-)
c.a.t.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 6 09:53:34 2004