Project

General

Profile

Actions

Submit #1398

open

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

Added by Anonymous almost 15 years ago. Updated over 2 years ago.

Status:
In Progress
Priority:
Normal
Assignee:
-
Category:
Userland
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:

Description

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'show 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


Files

Actions #1

Updated by Anonymous over 14 years ago

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.

Any thoughts about this one ?
If no objections are raised, I'm going to push it in ~1 week.

Cheers,
Stathis

Actions #2

Updated by Anonymous over 14 years ago

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.

Any thoughts about this one ?
If no objections are raised, I'm going to push it in ~1 week.

I'll tweak the example in the man page, add a few words in the text and commit it.

Reviewed by dillon@ and hasso@.

Cheers,
Stathis

Actions #3

Updated by dillon over 14 years ago

:Stathis Kamperis <> added the comment:
:
:> hdestroy(3) frees the memory pointed to by the hash key. In other words i=
:t
:> expects the user to always have malloc()'ed rather than used static alloc=
:ation
:> for the hash key. This doesn't apply to the data associated with the key.
:
:Any thoughts about this one ?
:If no objections are raised, I'm going to push it in ~1 week.
:
:Cheers,
:Stathis

Sure. Does anyone even use those functions any more? They aren't threadable.

-Matt

Actions #4

Updated by tuxillo about 9 years ago

  • Tracker changed from Bug to Submit
  • Description updated (diff)
  • Category set to Userland
  • Status changed from New to In Progress
  • Target version set to 4.2

Moving to submit.
Still relevant.

Actions #5

Updated by tuxillo almost 3 years ago

  • Target version changed from 4.2 to 6.0
Actions #6

Updated by tuxillo over 2 years ago

  • Description updated (diff)
Actions

Also available in: Atom PDF