Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Dec 2000 14:19:58 +1100
From:      Peter Jeremy <peter.jeremy@alcatel.com.au>
To:        Dag-Erling Smorgrav <des@ofug.org>
Cc:        arch@FreeBSD.ORG
Subject:   Re: Safe string formatting in the kernel
Message-ID:  <20001212141958.P69646@gsmx07.alcatel.com.au>
In-Reply-To: <xzpvgsq22ln.fsf@flood.ping.uio.no>; from des@ofug.org on Mon, Dec 11, 2000 at 08:13:24PM %2B0100
References:  <xzpsnnuq1hy.fsf@flood.ping.uio.no> <xzpvgsq22ln.fsf@flood.ping.uio.no>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2000-Dec-11 20:13:24 +0100, Dag-Erling Smorgrav <des@ofug.org> wrote:
>    http://people.freebsd.org/~des/software/sbuf-20001211b.diff

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.
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.

+struct sbuf {
+       char            *s_buf;         /* storage buffer */
+       size_t           s_size;        /* size of storage buffer */
+       size_t           s_len;         /* current length of string */
+       int              s_dynamic;     /* storage buffer must be freed */
+       int              s_done;        /* sbuf is finished and read-only */
+       int              s_flags;       /* flags */
+       struct sbuf     *s_next;        /* next in chain */
+};

The s_flags and s_next fields appear to be unused.  What is their
purpose?

2 int's (s_dynamic and s_done) to store 2 boolean values seems
excessive.  I agree that having a flags word is useful (even if
there aren't currently any caller values for it).  Once a flags
field is defined, all the flags should go there.

Also, I believe it would be better to have s_next adjacent to s_buf.
(To avoid padding before s_next - though the struct in its current
form will have 4 bytes of padding on the Alpha/IA64 anyway).


+       while (*ptr && s->s_len < s->s_size - 1)
+               s->s_buf[s->s_len++] = *ptr++;
+       s->s_buf[s->s_len] = '\0';

How about strlcpy()?

Peter


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?20001212141958.P69646>