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

[Jeffrey Hutzelman]

On Tue, 1 Jul 2003, R. Lindsay Todd wrote:

> I've already added %ll to the OpenAFS version.

Send me patches?  Or a ticket number, if you've already sent them to
openafs-bugs.

> Handling a negative format width specified as a %* parameter is broken,
> but I didn't need it, so didn't fix it.
>
> 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.

%p is portable for the caller, but not for the implementor.  In order to
print a pointer as hex, I must first convert it to some integer type.  How
do I know which one?

> 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.  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.  In the ancient past, I recall
> there being nl_printf variants (AIX, Ultrix, others?) that handled the
> positional arguments.  But I suspect that, unless there isa clever way
> to factor the code, this approach would lead to two implementations --
> not good.  I don't think positional arguments are an urgent priority.

Well, I'm not going to do it in the first pass in any case.  I haven't
thought about it in much detail, but I suspect that it won't be too hard
to keep one implementation, either by somehow factoring out the parsing
code or simply arranging to skip the first pass if support for positional
parameters is not enabled.  Maybe I'll look at it someday.