"Secure coding" audit checkers and Kerberos

[Tom Yu]

Nicolas Williams <Nicolas.Williams at sun.com> writes:

> On Wed, Oct 15, 2008 at 10:55:40PM -0400, Tom Yu wrote:
>> Nicolas Williams <Nicolas.Williams at sun.com> writes:
>> 
>> > On Wed, Oct 15, 2008 at 04:05:10PM -0500, John Hascall wrote:
>> >>   1) snprintf is also non-standard
>> >>   2) there are some horrible snprintf's out there,
>> >>      including ones which do little more than call sprintf!
>> >
>> > The MIT-krb5-uses-snprintf() train departed long ago.
>> >
>> > The Consortium might well decide to [continue to] provide portable
>> > versions of these, or that MIT krb5 will not support platforms which do
>> > not provide at least working snprintf().  I would support either
>> > position.
>> >
>> > I do object to avoiding *s*printf().  If ultimately that means that MIT
>> 
>> Do you mean to say that you object to *not* avoiding sprintf, i.e.,
>> that you object to retaining any uses of sprintf?
>
> No, I meant what I wrote.  I object to *s*printf() avoidance.  I do
> realize that that means checking for the correctness of a platform's
> implementation, and it might mean avoiding precision specifiers for %s
> (but I've not settled that yet; see my other reply).

Oh.  Do you mean the sprintf family of functions, rather than the
sprintf function in particular?  I may have misread your asterisks as
emphasis around the letter "s" rather than as globs.  I understand why
you might prefer using one of the sprintf functions to using some
unwieldy sequence of invocations of strcpy and strcat (or strlcpy and
strlcat).