[OpenAFS] Re: [OpenAFS-devel] Re: sprintf -> snprintf...

R. Lindsay Todd toddr@rpi.edu
Tue, 01 Jul 2003 14:06:11 -0400


Garance,

    Right now, afs_snprintf does NOT support the %j modifier.  I 
considered adding this, but went the route of instead implementing %ll 
for two reasons.  First, the existing pattern for the 64bit types was to 
use "long long", and %ll is definitely correct for those.  (Maybe this 
is lame.  But it was more expedient than autoconfiguring whether or not 
to include stdint.h, and where should that be done, etc. -- issues 
perhaps worth resolving now.)  Secondly, I have been using a tool called 
"splint" to check that parameters to *printf match the corresponding 
format codes.  Sadly, splint does not yet support the %j modifier. 
 There are hints that it will, eventually...  (Might not be too hard to 
patch.)

/Lindsay

Garance A Drosihn wrote:

> At 12:33 PM -0400 6/27/03, R. Lindsay Todd wrote:
>
>> [Coming late to this discussion, since I'm not on -info]
>>
>> As other have pointed out, there is an snprintf.c implementation
>> in src/util.  [...]  it does support features not found in every
>> sprintf, such as %llu and %lld formats for 64-bit integers.
>>
>> In trying to add LFS to the fileserver, I've needed to be able
>> to display integers that might be either 32- or 64-bit,
>> depending on compilation options.  [...] The cleanest solution
>> I've found, and what I've implemented, is to make cast these
>> values to afs_intmax_t or afs_uintmax_t, which are guaranteed
>> to be correctly formatted using %lld or %llu, respectively,
>> whether or not the AFS_64BIT_ENV is set.
>
>
> For what it's worth, freebsd-standards policy is to cast to
> uintmax_t or u_intmax_t, and then use %ju or %jd to print.
> (freebsd-standards is our project to follow posix/SUSv3
> standards as closely as possible).  Does afs_snprintf
> implement %j?
>
> I *think* it's true that %ll will not necessarily do the right
> thing for values of type intmax_t, since it is explicitly for
> long-long, while %j is explicitly for intmax_t.  Obviously
> those are often the same thing, but I suspect that they are
> allowed to be different.
>

-- 
R. Lindsay Todd                      email: toddr@rpi.edu
Senior Systems Programmer            phone: 518-276-2605
Rensselaer Polytechnic Institute     fax:   518-276-2809
Troy, NY 12180-3590                  WWW:   http://www.rpi.edu/~toddr