eeh@netbsd.org writes:
> 	eeh@netbsd.org writes:
> 	> 	PROP_WAIT does not make sense on a property structure.  So
> 	> 	you want to pass 3-4 different `flag' parameters to these calls?
> 	> 
> 	> Actually, come to think about it, the only flag that would
> 	> ever be actually attached to a property would be PROP_STRING,
> 	> and I hope to find some way of marking a property as a string
> 	> without requiring an extra flag field.  So, for the most part,
> 	> the flags change the behavior of specific functions.
> 
> 	Uh, how about PROP_CONST?
> 
> That would simply change the method used to allocate the property
> structure not to allocate storage for the property.

Hmm.  Perhaps i'd been thinking about the internals wrong.  I'd
figured properties would be represented by:

	struct prop_header {
	}
	prop data

i.e. there'd be no point in wasting the space on a pointer in the
header, because you know where the data is...  then in the
"PROP_CONST" case, you'd make 'prop data' be the pointer...


Actually, wouldn't you need to know about PROP_CONST when you _delete_
the property, or copy it?  I.e., i'd think that:

	(1) copying a const property wouldn't copy the actual data,
	    just take another ptr to it.

	(2) deletion of a const property shouldn't require the
	    'const'ness to be specified.  (It's just gonna be a
	    source of errors, and it's _really_ easy to fix in the
	    interface!)

So I think you'd need a PROP_CONST flag even if you're including a ptr
to data in the 'property header' or whatever.



cgd