[issue1398] hdestroy(3) restricts hash key to point to malloc'ed space

[Stathis Kamperis (via DragonFly issue tracker)]

New submission from Stathis Kamperis <ekamperi at gmail.com>:

Salute.

hdestroy(3) frees the memory pointed to by the hash key. In other words it
expects the user to always have malloc()'ed rather than used static allocation
for the hash key. This doesn't apply to the data associated with the key.

Although POSIX standard doesn't say much on this particular topic:

1) This is unnecessarily restrictive. If the user wants static allocation, we
should allow this. If she wants dynamic then let *her* free the memory she
malloc()'ed.

2) It is in conflict with the example code in the POSIX page. The code 
segfaults if you add an hdestroy() call in the end of it.

3) Programs that target other implementations may segfault in DragonFly (that's
how I discovered it). AFAIK sunOS 5.10 and a recent glibc work fine, whereas
{Net, Free, DragonFly}BSD all are affected because they share the same code.
(One could argue that all programs written with the *BSD version in mind would
result in a memory leak. But still I think these programs (if any) should be fixed.)

Any thoughts ?

Cheers,
Stathis

----------
assignedto: Beket
files: 0001-hdestroy-3-Don-t-call-free-3-for-each-hash-key.patch
messages: 6736
nosy: Beket
status: unread
title: hdestroy(3) restricts hash key to point to malloc'ed space

_____________________________________________________
DragonFly issue tracker <bugs at lists.dragonflybsd.org>
<http://bugs.dragonflybsd.org/issue1398>
_____________________________________________________Attachment:
0001-hdestroy-3-Don-t-call-free-3-for-each-hash-key.patch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bin00004.bin
Type: application/octet-stream
Size: 2322 bytes
Desc: "Description: Binary data"
URL: <http://lists.dragonflybsd.org/pipermail/bugs/attachments/20090610/e36e9356/attachment-0021.bin>