R Lindsay Todd <[EMAIL PROTECTED]> writes: > How is %p non-portable? Is there a reason you can't just get the > pointer as a void*? Even if you have a platform with different pointer > types, mustn't its printf treat the pointer as void*? Right now there > are lots of places in the OpenAFS code where pointers are printed as > %x. Now *that* is non-portable.
It's not possible to implement %p portably in a pure C snprintf implementation, since correctly implementing %p may require knowledge of the pointer format of the host platform. (Think of segmented addressing, for example.) This may or may not be worth worrying about. I think that every platform that OpenAFS currently runs on uses ordinary flat pointers that can be meaningfully cast to an intmax_t and then printed with %x. Basically, the snprintf implementation would have to print pointers with %x or the moral equivalent, and therefore our local %p implementation would be precisely as non-portable as the existing %x code (which is an argument that OpenAFS at present doesn't care). > Right now, I don't know of any use of the return code of afs_snprintf. Once you start using snprintf widely and properly, particularly if you tackle trying to eliminate as many static buffers as you can in userspace code, I predict that you will start caring a lot. > But it would be useful if we find we want afs_printf, or some other > standardized logging, without imposing a maximum length on the formatted > output. So I'd categorize this as a good change, but not urgent. *nod*. > As for positional arguments, I'm a bit iffy about them. Hopefully > OpenAFS become popular enough that we worry about i18n issues, message > catalogs, etc. At such time as someone goes to add real i18n support to OpenAFS, I expect that implementing positional parameters in afs_snprintf will be the least of their worries. I'd defer that until someone actually sees a need for it, unless someone really feels like implementing positional parameters as a fun programming exercise some afternoon. > But as you observe, positional arguments require two passes over the > format string. While I'm not too worried about the speed of > afs_snprintf, there are a few places it would be nice to know we haven't > unnecessarily slowed it down. I'd be pretty suspicious of any case where positional arguments to snprintf were used on a hot code path (generally, user output that can be meaningfully internationalized is not a hot code path). I expect that it's possible to code positional argument support such that it doesn't add a performance penalty if it's not used. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
