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

[Russ Allbery]

R Lindsay Todd <toddr@rpi.edu> 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 (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>