[OpenAFS] Re: [OpenAFS-devel] Re: sprintf -> snprintf...
Derek Atkins
warlord@MIT.EDU
27 Jun 2003 15:20:36 -0400
intmax_t is not a portable construct (yet)
-derek
Garance A Drosihn <drosih@rpi.edu> writes:
> 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.
>
> --
> Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
> Senior Systems Programmer or gad@freebsd.org
> Rensselaer Polytechnic Institute or drosih@rpi.edu
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available