OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Vuln-Dev Archives: Re: Secure coding in C (was Re: Administrivi

Re: Secure coding in C (was Re: Administrivia #4883)

Subject: Re: Secure coding in C (was Re: Administrivia #4883)
From: Blue Boar (BlueBoarTHIEVCO.COM)
Date: Fri Jan 21 2000 - 02:38:45 CST

Seth R Arnold wrote:
>
> On Thu, Jan 20, 2000 at 11:57:38PM -0800, Marco Walther wrote:
> > And the same paragraph from the Solaris 8 snprintf man page:
> >
> > " The snprintf() function is identical to sprintf() with the
> > addition of the argument n, which specifies the size of the
> > buffer referred to by s. The buffer is always terminated
> > with the null byte."
> >
> > I've tried a small test case on Solaris 7 and it looks like the man is
> > not correct there?!
> >
> > #include <stdio.h>
> >
> > main()
> > {
> > char b[10];
> >
> > snprintf(b, 10, "I'm a really long test string!\n");
> >
> > printf("b[9]= %d\n", (int)b[9]);
> > }
> >
> > returns `b[9]= 0'
>
> Marco, might I be so bold to ask what you expected to happen? AFAICT, that
> is correct behavior..
>

I *believe* (And I'll let Marco explain himself too, if and when the post
arrives) that what he's trying to demonstrate is that it does in fact
work correctly, as you've said. The problem was that the Solaris 7 docs
say it won't necessarily work correctly, even though it looks like it does.

For the benefit of those on the list who haven't followed this thread
as well as they would have liked, I'm going to do a verbose explanation.

In the C language, strings are supposed to end in a 0 (null character)
so that various functions, like printf, know when the string stops. If
there is no 0, it prints right off the end of the string, causing
weird output.

So, the test above was to take a 10 character buffer, and try to
use snprintf to cram something longer in it. If snprintf was
broken like the man page suggested, then the 10th character
would have been the letter l from "really", instead of a zero
as it should be. However, it works just fine, and the 10th
character is a 0.

And that's the right thing.. it just means the documentation needs
an update. :)

                                        BB

This archive was generated by hypermail 2b27 : Fri Jan 21 2000 - 02:42:31 CST