Dan Price writes:
> FWIW, I had simply assumed that the interface would mimic most other
> memory allocating interface: strdup(mystr, KM_SLEEP) (or if we're
> worried that people will make mistakes if it is called "strdup" then
> call it kstrdup). But again, I think this issue is for the implementor
I'd thought the accepted way to do this was to prefix with "ddi_" if
it was different from the user-space equivalent. We've done this with
other functions, such as ddi_strtol(9F).
I agree it ought to carry allocation flags through, but I also agree
that it's possibly a dubious interface. kmem_free requires the user
to pass in the original buffer size, so a typical usage pattern is
like this:
foo->foo_len = strlen(blah) + 1;
foo->foo_str = kmem_alloc(foo->foo_len, KM_SLEEP);
strcpy(foo->foo_str, blah);
...
kmem_free(foo->foo_str, foo->foo_len);
... meaning that callers usually need to know something about the
string length in order to use 'strdup' in a reasonable way.
Doing the strlen() twice isn't just a duplicate operation. If it's
done at kmem_free time, it's risky, and relies on users of that string
to avoid truncating it.
On top of that, it's often helpful to think about organizing the data
structures in a way that avoids lots of tiny allocations -- as strdup
encourages.
But I guess I don't care much. If someone feels strdup is useful,
have at it.
> to decide.
>
> Probably this belongs on osol-code... :/
Redirecting ...
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
