Vulnerability Development mailing list archives
Re: Secure coding in C (was Re: Administrivia #4883)
From: imp () VILLAGE ORG (Warner Losh)
Date: Fri, 21 Jan 2000 10:36:25 -0700
In message <20000120194230.6083.qmail () securityfocus com> "Tellier, Brock" writes: : In message <<A HREF="mailto:Pine.LNX.4.03.10001161207550.7428-100000 () brian citynet net">Pine.LNX.4.03.10001161207550.7428-100000 () brian citynet net</A>> Brian Masney writes: : : On some UNIX systems, snprintf does not guarentee that it will nul : : terminate the string. I know on some older versions of libc5 (sorry, : : don't have an exact version), if the buffer you was writing to got to the : : max size you passed it, it would stop there without adding the nul. So, : : you'll run into problems later on if you pass it to a string : : function (like strcpy()) : : >snprintf is *DEFINED* to NUL terminate the string. Systems >that don't : >do this are broken. That's why it is used as widely as it >is. : : From the Solaris 7 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 terminated with the null byte only if space is available. : --------------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^ : : Meaning that one shouldn't copy more than bufsize - 1 bytes or risk a bof later on. I don't get the same reading. "The buffer is terminated with the null[sic] byte only if space is available" meand that if n = 0 no NUL will be written. Otherwise there will be space and the NUL is writtent. Warner
Current thread:
- Re: things to break.., (continued)
- Re: things to break.. John Galt (Jan 24)
- Re: things to break.. Matt Conover (Jan 25)
- Re: things to break.. Simple Nomad (Jan 25)
- Re: things to break.. Jordan Ritter (Jan 25)
- ICQ Pass Cracker. WolF Knox (Jan 26)
- Re: ICQ Pass Cracker. Blue Boar (Jan 26)
- Re: ICQ Pass Cracker. Usman (Jan 26)
- Re: ICQ Pass Cracker. Vladimir Dubrovin (Jan 27)
- Shadow kjkotas (Jan 24)
- Re: Secure coding in C (was Re: Administrivia #4883) Marc Slemko (Jan 21)
- Re: Secure coding in C (was Re: Administrivia #4883) Warner Losh (Jan 21)
- Re: Secure coding in C (was Re: Administrivia #4883) Blue Boar (Jan 15)
- Re: Secure coding in C (was Re: Administrivia #4883) Brian Kifiak (Jan 16)
- Re: Administrivia #4883 Blue Boar (Jan 15)
- ICQ (Was Re: Administrivia #4883) Imran Ghory (Jan 16)