eeh@netbsd.org writes:
> | what does it mean?  since they don't have an obvious fixed size,
> | they're not strictly speaking an array...  (or do you mean, string
> | pointer and array of string pointers... i don't think so?)
> 
> No, an array of strings is a buffer full of NUL terminated strings
> up to the length of the buffer.  So you go traverse the buffer, 
> looking for NULs, and set your pointers 1 byte beyond that until
> you run out of buffer.

OK.  (BTW, Assuming you think this type of representation of a list of
NUL-terminated strings is The Right Thing, why did you add an extra
NUL to the end of the list of <whichever> names returned by sysctl?
why not just terminate in the same way, i.e., by running out of
buffer?)

> | > | I'm thinking that maybe 'setprop' should reject an attempt to change
> | > | an existing property's type.  not sure tho.
> | > 
> | > Once again, I don't see why the database code should be setting policy.
> |
> | That seems reasonable.  On the other hand, can you think of real cases
> | where you _would_ want the type to change at run time?
> 
> Switching from a single integer to an array of integers, or the other
> way around, is certainly understandable.

in general, from a single foo to an array of foo.  but i'm still not
sure...  the thought goes something like:

if you tolerate an array of foo, you can say "array of foo" up front,
even if there's only one element in that array.

If that's not desirable, the code could explicitly allow that case
(conversion from a single element to an array w/ elements the same
size as the original) w/o much trouble, i think...


> | Is it necessarily true that different databases _must_ have different
> | 'types' of contents?  e.g. one could imagine (and this is totally
> | constructed 8-) something like:
> |
> | 	default audio device db:
> |
> | 		objects: channels: input, output, mixer, ... ?
> |
> | 		properties associated with those objects:
> | 			(who knows, something about audio).
> |
> | 	audio device a db:
> |
> | 		same type of thing
> |
> | 	audio device b db:
> |
> | 		same thing...
> |
> | then at init of a device you might want to copy all of its params from
> | the default params...
> |
> | i suppose you could use a single db to do this, but then you need to
> | construct object ids out of ptrs + channel numbers, etc.  kinda gross.
> 
> In this case I'd say you really wanted to implement this with one database,
> and the object identifiers would be pointers to individual channels....
> 
> The problem with allowing copying from one database to another is that
> the object identifier space is potentially completely different.  Writing
> code to do that is quite trivial, but I'm not sure I want to consider what
> the implication of allowing that sort of operation would be on the database
> abstraction.

Err, I was specifically thinking of something along the lines of:

	copy all properties of object ob1 in db1
	so that they're attached to object ob1 in db2.

(i.e., the user would need to specify the object in the second, and
therefore issues of the 'object identifier space' and/or meanings of
the object ids would be theirs to sort out.  I _wasn't_ thinking "copy
this object into this other database, with the same object
identifier.)

Anyway, if there's a need for it in the future, it shouldn't be hard
to add, so *punt*.


> Maybe we should change all references of `quad' to `int64_t' in all the
> manpages.

probably.  8-)


> | perhaps the right answer here is (assuming the desire is to keep
> | sysctl's 'mib' a set of integers) to redefine them to be uint32_t's or
> | int32_t's...
> |
> | I think that'd solve both problems, w/ no compatibility issues for
> | current platforms.
> 
> That's a good idea, but outside the scope of this.

it's not _quite_ outside the scope of this.  you're shoehorning a
(possibly-)wider fixed-size type down on to the existing array of
'int's.

since you aren't actually guaranteed that an 'int' will have a fixed
size, and it's important to know how they map... you're forced to
either assume something about 'int', or fix the use of 'int's.

Historically, assumptions about non-fixed-size type sizes have been
bad ones.  8-)


> I prefer to have explicit conversions.  They cause less problems in the 
> long run than passing blocks of memory.

I think I agree.


> I'll change the wording to define 
> it as explicitly big-endian.  I suppose providing a set of macros for this 
> operation would be a good idea.

Yes, good.



thanks!

chris