From owner-freebsd-arch@FreeBSD.ORG Fri Jul 5 20:10:43 2013 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 081AFFCD; Fri, 5 Jul 2013 20:10:43 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id C52B11090; Fri, 5 Jul 2013 20:10:42 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 939193EB30; Fri, 5 Jul 2013 20:10:41 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.7/8.14.7) with ESMTP id r65KAfkw060318; Fri, 5 Jul 2013 20:10:41 GMT (envelope-from phk@phk.freebsd.dk) To: Pawel Jakub Dawidek Subject: Re: General purpose library for name/value pairs. In-reply-to: <20130705195255.GB25842@garage.freebsd.pl> From: "Poul-Henning Kamp" References: <20130704215329.GG1402@garage.freebsd.pl> <4818.1373008073@critter.freebsd.dk> <20130705195255.GB25842@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1 Date: Fri, 05 Jul 2013 20:10:40 +0000 Message-ID: <60317.1373055040@critter.freebsd.dk> Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 20:10:43 -0000 In message <20130705195255.GB25842@garage.freebsd.pl>, Pawel Jakub Dawidek writ es: >To be honest I'd much prefer not to support duplicates, because arrays >of values are supported as well as nesting. Not supporting duplicates >would simplify implementation a bit. So why do you support it ? >> Also remember a function for debugging which renders a nvlist_t (into >> a sbuf ?) > >Currently I have: > > void nvlist_dump(const nvlist_t *nvl, int fd); > void nvlist_fdump(const nvlist_t *nvl, FILE *out); I would just make one, and have it return an sbuf. That way the same code can be used in kernel and userland, and people get to decide where it should end up and how. >> Do consider having these functions in a variant with a default >> argument, so that people don't have to wrap each optioanl n/v pair >> in an if(). > >Using default value to report a problem [...] Uhm, it's not to report problems, it's to implement default values for non-specified names: give me $foo or if there is no $foo, give me "32" The return value should always be a "int where zero means OK" style error indicator, the returned value should go into a pointer arg. >I was considering this as well, but there is a lot of functions as it is >now [...] Yes, hate to say it, but that to me indicates that you're not quite on the right path. Maybe the basic n/v should just do strings, and interpretation of strings be a layer above ? >> [error string API] >Fine idea, but doesn't seem to directly related to libnv. No, but you'll have a hard time emitting meaningful errors from libnv without such a facility. Right now everybody rolls their own, getaddrinfo has its own, GEOM has its own, netgraph has its own... At some point we should call a stop, and I'd say "before libnv grows one too" is at good time :-) >There is only a problem with translating those messages, which we keep >avoiding. You know ? Screw that! Having usable errors only in english is far better than having only "Invalid argument" in all the languages of the world. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.