From owner-freebsd-arch Tue Dec 12 6:35:38 2000 From owner-freebsd-arch@FreeBSD.ORG Tue Dec 12 06:35:35 2000 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id A6FD637B404 for ; Tue, 12 Dec 2000 06:35:34 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id PAA61075; Tue, 12 Dec 2000 15:35:24 +0100 (CET) (envelope-from des@ofug.org) Sender: des@ofug.org X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Jake Burkholder Cc: arch@FreeBSD.ORG Subject: Re: Safe string formatting in the kernel References: <20001211215816.1E73EBA7D@io.yi.org> From: Dag-Erling Smorgrav Date: 12 Dec 2000 15:35:23 +0100 In-Reply-To: Jake Burkholder's message of "Mon, 11 Dec 2000 13:58:15 -0800" Message-ID: Lines: 68 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jake Burkholder writes: > This is interesting. I hoped it would be :) > Aren't malloc types usually capital letters that look like a flag? > like M_SBUF? You're probably right; I didn't check. I didn't think it mattered since it's only used internally in subr_sbuf.c. > Why not make s_dynamic live in s_flags? Maybe s_done also? Good idea. Don't know why it didn't occur to me. > Maybe also have a flag S_INITED instead of using s_buf as a flag? s_buf isn't used as a flag except in assertions. > If you're going to make a list shouldn't you use the queue(3) macros? Because I don't really want a list. I'm not even sure I need s_next. I haven't decided how to implement sbuf growth yet; I added s_next because I thought there was a fair chance I'd need it and didn't want to change the struct later. But I see now that I need to modify the struct anyway, so I'll probably discard s_next and either use queue macros or something totally different. The rationale for using a chain, by the way, is that if you need to extend the buffer several times, you want to put off concatenating segments until sbuf_finish(). If it weren't for that, you could just malloc() a new buffer, copy the old data into the new buffer, free the old buffer, and point s_buf at the new buffer. > > +sbuf_putc(struct sbuf *s, int c) > ... > + s->s_buf[s->s_len] = 0; > > '\0' ? Yes, that was a slip. > +sbuf_printf(struct sbuf *s, char *fmt, ...) > ... > + len = kvprintf(fmt, _sbuf_pchar, s, 10, ap); > > If the idea is to invent our own formats, and sbuf_printf calls kvprintf, > then the new formats need to be added to kvprintf right? The idea is not to invent our own formats. At least, the idea is not to have sbuf_printf() support formats which printf() or sprintf() or log() don't. If you're thinking of my %a / %A patch, it is totally unrelated to this matter. > In that case > one would be able to use them with just normal kernel printf which seems > like something we're trying to avoid. Maybe some kind of printf format > switch table would be useful? That may be a good idea, but it's way outside the scope of the sbuf interface. 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