From owner-freebsd-standards Sat Apr 6 3:39:20 2002 Delivered-To: freebsd-standards@freebsd.org Received: from bazooka.trit.org (bazooka.trit.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id D40A937B400 for ; Sat, 6 Apr 2002 03:39:18 -0800 (PST) Received: by bazooka.trit.org (Postfix, from userid 1000) id 03E623E2F; Sat, 6 Apr 2002 11:39:14 +0000 (UTC) Received: from bazooka (localhost [127.0.0.1]) by bazooka.trit.org (Postfix) with ESMTP id 026053C12E; Sat, 6 Apr 2002 11:39:14 +0000 (UTC) To: Bruce Evans Cc: standards@FreeBSD.ORG Subject: Re: %j length modifier in kernel printf In-Reply-To: <20020405184249.S3947-100000@gamplex.bde.org>; from bde@zeta.org.au on "Fri, 5 Apr 2002 18:49:19 +1000 (EST)" Date: Sat, 06 Apr 2002 11:39:08 +0000 From: Dima Dorfman Message-Id: <20020406113914.03E623E2F@bazooka.trit.org> Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bruce Evans wrote: > On Fri, 5 Apr 2002, Dima Dorfman wrote: > > > I've implemented the %j and %z (named %Z (for now?), since %z is > > signed hex) length modifiers in the kernel printf(). The patch below > > has been tested on i386, and appears to work okay. My primary concern > > with it is breaking sign extension stuff; I've run tests to check that > > I didn't break it completely, but it's very possible that I still > > missed some corner cases. > > I don't like the restructuring of the code (lm functions). I think > the kernel kvprintf should be much like the userland __vfprintf except > for not having support for floating point (yet?) or the positional > parameters bloat (ever). Are the significant complications for the > extra formats in the kernel printf? I didn't see any particular reason to model it on __vfprintf (besides that it might have been less work, but it didn't appear to be so to me). The latter needs to be concerned with things that the kernel printf doesn't care about (you mentioned floating point stuff and positional parameters), so is likely to be more complicated than the kernel printf needs to be. Therefore, keeping them in sync won't buy is much since they'll always be significantly different. What didn't you like about the lm functions? I admit they aren't pretty, but the *ARG() macros in __vfprintf are hardly better. Is this the only part that you thought was unlike __vfprintf? Thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message