[PATCH] weak for calloc()

[Martin Pohlack]

Hi again,

recently I ported the dietLibC to a non--unix-like OS (DROPS,
http://os.inf.tu-dresden.de/drops/). As DROPS is based on a microkernel
there are no such fancy syscalls as gettimeofday() or mmap().

Consequently, colleagues and me had to come up with a set of "backends"
to implement the missing functionality.

One such backend is a memory backend, which just provides anonymous
mmap(). However, there were reasons to completely exchange the malloc()
functions. Therefore, it is helpful that malloc(), realloc(), and
free() are defined as weak symbols. For some reasons, calloc() is not.
Is there any reason for this?

Anyway here is a patch for dietlibc/lib/alloc.c:



--- alloc.c 21 Dec 2003 12:06:36 -0000 1.35
+++ alloc.c 27 Jan 2004 00:31:19 -0000
@@ -175,7 +175,8 @@
void* __libc_malloc(size_t size) __attribute__((alias("_alloc_libc_malloc")));
void* malloc(size_t size) __attribute__((weak,alias("_alloc_libc_malloc")));

-void *calloc(size_t nmemb, size_t _size) {
+void* calloc(size_t nmemb, size_t _size) __attribute__((weak));
+void* calloc(size_t nmemb, size_t _size) {
register size_t size=_size*nmemb;
if (nmemb && size/nmemb!=_size) {
(*__errno_location())=ENOMEM;
@@ -234,4 +235,3 @@
return ptr;
}
void* realloc(void* ptr, size_t size) __attribute__((weak,alias("__libc_realloc")));
-




Please let me know, if there is a better way to propose changes than
this list. Probably I will come up with more.

[Felix von Leitner]

Post by Martin Pohlack
recently I ported the dietLibC to a non--unix-like OS (DROPS,
http://os.inf.tu-dresden.de/drops/). As DROPS is based on a microkernel
there are no such fancy syscalls as gettimeofday() or mmap().
Consequently, colleagues and me had to come up with a set of "backends"
to implement the missing functionality.
One such backend is a memory backend, which just provides anonymous
mmap(). However, there were reasons to completely exchange the malloc()
functions. Therefore, it is helpful that malloc(), realloc(), and
free() are defined as weak symbols. For some reasons, calloc() is not.
Is there any reason for this?

Well, we thought people may want to override malloc and free, but since
calloc is just a trivial wrapper, we didn't anticipate anyone wanting to
overwrite it.

But there is no fundamental reason why calloc shouldn't be weak.

Post by Martin Pohlack
Please let me know, if there is a better way to propose changes than
this list. Probably I will come up with more.

You can also just send them to me: felix-dietlibc(at)fefe.de

But if you send them to the list, maybe Olaf sees them first and applies
them to the CVS, he also has write access.

Felix

[Martin Pohlack]

Post by Felix von Leitner

Post by Martin Pohlack
recently I ported the dietLibC to a non--unix-like OS (DROPS,
http://os.inf.tu-dresden.de/drops/). As DROPS is based on a microkernel
there are no such fancy syscalls as gettimeofday() or mmap().
Consequently, colleagues and me had to come up with a set of "backends"
to implement the missing functionality.
One such backend is a memory backend, which just provides anonymous
mmap(). However, there were reasons to completely exchange the malloc()
functions. Therefore, it is helpful that malloc(), realloc(), and
free() are defined as weak symbols. For some reasons, calloc() is not.
Is there any reason for this?

Well, we thought people may want to override malloc and free, but since
calloc is just a trivial wrapper, we didn't anticipate anyone wanting to
overwrite it.

In the dietlibc's implementation all memory is set to zero (if its
small, it's done on free, if it's a larger block mmap() does it). So,
calloc() *can be* a simple wrapper.

malloc() does not necessarily has to deliver zero'd memory. So, calloc
is not always a simple wrapper, it may additionally zero-out the memory
or get it from a completely different pool (e.g. in our System).

Post by Felix von Leitner
But there is no fundamental reason why calloc shouldn't be weak.

So, I would prefer the "weak" solution.

Post by Felix von Leitner

Post by Martin Pohlack
Please let me know, if there is a better way to propose changes than
this list. Probably I will come up with more.

You can also just send them to me: felix-dietlibc(at)fefe.de
But if you send them to the list, maybe Olaf sees them first and applies
them to the CVS, he also has write access.
Felix

Martin