This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/15009] New: tdestroy() should allow passing 'NULL' for 'free_node' callback
- From: "ivosh at ivosh dot net" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 10 Jan 2013 14:06:03 +0000
- Subject: [Bug libc/15009] New: tdestroy() should allow passing 'NULL' for 'free_node' callback
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=15009
Bug #: 15009
Summary: tdestroy() should allow passing 'NULL' for 'free_node'
callback
Product: glibc
Version: 2.17
Status: NEW
Severity: normal
Priority: P2
Component: libc
AssignedTo: unassigned@sourceware.org
ReportedBy: ivosh@ivosh.net
CC: drepper.fsp@gmail.com
Classification: Unclassified
Created attachment 6811
--> http://sourceware.org/bugzilla/attachment.cgi?id=6811
source code patch proposal
This is a modest enhancement which would make lives of many developers
a bit more cheerful.
Glibc contains function tdestroy() which is not specified by any standard.
This function is very handy because it allows destroying whole binary
search tree at once.
However the 'free_node' callback cannot be NULL even if no work
is necessary (keys are integers, for example).
I can only speculate why it is so. The only valid reason might be performance:
(*freefct) ((void *) root->key);
could be called directly in tdestroy_recurse() without checking for
non-NULL first.
However that puts unnecessary burden on the application developers,
although the manpage says that 'free_node' in that case must point to
an empty function. Even glibc itself has such empty function (freenop).
Glibc should be more friendly in this case and allow to pass NULL
for 'free_node".
See the attached patch with my proposal.
If the patch will be accepted, documentation and tdestroy()
invocation(s) with empty functions need to be revisited.
I can supply these as well.
------------------------------
Required information:
Glibc version: 2.17
Host/build/target: any
> uname -a
Linux xxxxx 3.2.0-35-generic #55-Ubuntu SMP Wed Dec 5 17:42:16 UTC 2012 x86_64
x86_64 x86_64 GNU/Linux
> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
> ld -v
GNU ld (GNU Binutils for Ubuntu) 2.22
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.