Date: 12 Dec 2000 15:48:32 +0100 From: Dag-Erling Smorgrav <des@ofug.org> To: Peter Jeremy <peter.jeremy@alcatel.com.au> Cc: arch@FreeBSD.ORG Subject: Re: Safe string formatting in the kernel Message-ID: <xzp8zpl66gv.fsf@flood.ping.uio.no> In-Reply-To: Peter Jeremy's message of "Tue, 12 Dec 2000 14:19:58 %2B1100" References: <xzpsnnuq1hy.fsf@flood.ping.uio.no> <xzpvgsq22ln.fsf@flood.ping.uio.no> <20001212141958.P69646@gsmx07.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy <peter.jeremy@alcatel.com.au> writes: > Overall the purpose of this isn't clear to me. It doesn't appear to > have any real advantages over using the standard string functions. This has been explained elsewhere in this thread both by Poul-Henning and myself. > The main advantage I can see for having a proper set of string > functions would be to support dynamic (growable) strings and sbuf uses a > fixed size buffer. Please read the comments that precede the patch. > The s_flags and s_next fields appear to be unused. What is their > purpose? This is documented in patch itself and in the comments that precede it. > 2 int's (s_dynamic and s_done) to store 2 boolean values seems > excessive. Yes, I'll move those into s_flags. > How about strlcpy()? I suppose sbuf_cat() and sbuf_cpy() could be modified to take an additional size argument (with a magic value, e.g. (size_t)(-1), meaning "the whole shebang") which would allow them to function in a manner similar to strlcat() and strlcpy(). Poul-Henning didn't specify that in his design, and I didn't think of it myself (I implemented his design almost to the letter, except for adding the flags argument to sbuf_new() and adding sbuf_setpos() and sbuf_putc()) DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzp8zpl66gv.fsf>