From owner-freebsd-hackers Fri Oct 30 13:07:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA25496 for freebsd-hackers-outgoing; Fri, 30 Oct 1998 13:07:02 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA25491 for ; Fri, 30 Oct 1998 13:07:01 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id NAA02040; Fri, 30 Oct 1998 13:06:10 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199810302106.NAA02040@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Archie Cobbs cc: mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: scanf in the kernel? In-reply-to: Your message of "Fri, 30 Oct 1998 13:00:58 PST." <199810302100.NAA18888@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Oct 1998 13:06:10 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Archie Cobbs writes: > > > Just wondering what the general feeling would be about having scanf in > > > the kernel? As we move towards more abstract representations of things > > > (eg. device names), it's becoming more important to be able to parse > > > strings inside the kernel. > > > > > > Doing this in hand-rolled code is tedious, error-prone and results in > > > code that can be hard to read and maintain (as everyone does it their > > > own way). > > > > > > If this isn't totally repulsive, I'll roll a somewhat smaller version > > > of the libc vfscanf for general approval. > > Also- > Seems like the kernel was missing memmove(), memcpy(), and/or memset() > at some point. I like using these better than bcopy()/bzero() because > they are more ANSI and portable... I think there'd be some BSD traditionalist sentiment here. But you can fake them up easily enough, so if there's a compelling need this could be done, yes. > And what about snprintf()? Would that be hard to add to the existing > printf() functionality? The kernel is definitely one place you > don't want to overflow string buffers... I don't know. Want to take a quick look and tell us? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message