Date: 12 Dec 2000 15:35:23 +0100 From: Dag-Erling Smorgrav <des@ofug.org> To: Jake Burkholder <jburkhol@home.com> Cc: arch@FreeBSD.ORG Subject: Re: Safe string formatting in the kernel Message-ID: <xzpn1e1672s.fsf@flood.ping.uio.no> In-Reply-To: Jake Burkholder's message of "Mon, 11 Dec 2000 13:58:15 -0800" References: <20001211215816.1E73EBA7D@io.yi.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Jake Burkholder <jburkhol@home.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzpn1e1672s.fsf>