intmax_t is not a portable construct (yet) -derek
Garance A Drosihn <[EMAIL PROTECTED]> 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 = [EMAIL PROTECTED] > Senior Systems Programmer or [EMAIL PROTECTED] > Rensselaer Polytechnic Institute or [EMAIL PROTECTED] > _______________________________________________ > OpenAFS-devel mailing list > [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] PGP key available _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
