Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 05 Jul 2013 20:10:40 +0000
From:      "Poul-Henning Kamp" <phk@phk.freebsd.dk>
To:        Pawel Jakub Dawidek <pjd@FreeBSD.org>
Cc:        arch@FreeBSD.org
Subject:   Re: General purpose library for name/value pairs.
Message-ID:  <60317.1373055040@critter.freebsd.dk>
In-Reply-To: <20130705195255.GB25842@garage.freebsd.pl>
References:  <20130704215329.GG1402@garage.freebsd.pl> <4818.1373008073@critter.freebsd.dk> <20130705195255.GB25842@garage.freebsd.pl>

next in thread | previous in thread | raw e-mail | index | archive | help
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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?60317.1373055040>