[libvirt] [PATCH] build: trivial fix error: implicit declaration of function 'malloc'
Fixes this error when building with -Werror on Alpine Linux: util/processinfo.c: In function 'virProcessInfoSetAffinity': util/processinfo.c:52:5: error: implicit declaration of function 'malloc' [-Werror=implicit-function-declaration] Signed-off-by: Natanael Copa <ncopa@alpinelinux.org> --- src/util/processinfo.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/util/processinfo.c b/src/util/processinfo.c index c3648d4..b8c60eb 100644 --- a/src/util/processinfo.c +++ b/src/util/processinfo.c @@ -21,6 +21,7 @@ #include <config.h> +#include <stdlib.h> #include <sched.h> #include "processinfo.h" -- 1.8.0
On Thu, Nov 22, 2012 at 01:28:08PM +0100, Natanael Copa wrote:
Fixes this error when building with -Werror on Alpine Linux:
util/processinfo.c: In function 'virProcessInfoSetAffinity': util/processinfo.c:52:5: error: implicit declaration of function 'malloc' [-Werror=implicit-function-declaration]
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org> --- src/util/processinfo.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/src/util/processinfo.c b/src/util/processinfo.c index c3648d4..b8c60eb 100644 --- a/src/util/processinfo.c +++ b/src/util/processinfo.c @@ -21,6 +21,7 @@
#include <config.h>
+#include <stdlib.h> #include <sched.h>
#include "processinfo.h"
Let me guess, this is a failure seen with uclibc too ? The line that warning corresponds to is mask = CPU_ALLOC(numcpus); On glibc this is defined to a function _sched_cpualloc(), hence we don't see a warning. If your headers are defining this in terms of malloc(), then IMHO, the sched.h should be including stdlib.h on our behalf. IOW, I think this is a bug in the c library headers That all said, I'm not against adding this workaround in libvirt, provided the c library bug is reported upstream. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Thu, 22 Nov 2012 13:36:14 +0000 "Daniel P. Berrange" <berrange@redhat.com> wrote:
On Thu, Nov 22, 2012 at 01:28:08PM +0100, Natanael Copa wrote:
Fixes this error when building with -Werror on Alpine Linux: ... --- a/src/util/processinfo.c +++ b/src/util/processinfo.c @@ -21,6 +21,7 @@
#include <config.h>
+#include <stdlib.h> #include <sched.h>
#include "processinfo.h"
Let me guess, this is a failure seen with uclibc too ? The line that warning corresponds to is
mask = CPU_ALLOC(numcpus);
On glibc this is defined to a function _sched_cpualloc(), hence we don't see a warning.
If your headers are defining this in terms of malloc(), then IMHO, the sched.h should be including stdlib.h on our behalf. IOW, I think this is a bug in the c library headers
You are right. uclibc does this: #if 0 /* in uClibc we use macros */ extern cpu_set_t *__sched_cpualloc (size_t __count) __THROW __wur; extern void __sched_cpufree (cpu_set_t *__set) __THROW; #else # define __sched_cpualloc(cnt) ((cpu_set_t *)malloc(__CPU_ALLOC_SIZE(cnt))) # define __sched_cpufree(__set) free(__set) #endif And since this is only a warning, I don't think its worth the effort. Thanks! -nc
On 11/22/2012 06:46 AM, Natanael Copa wrote:
If your headers are defining this in terms of malloc(), then IMHO, the sched.h should be including stdlib.h on our behalf. IOW, I think this is a bug in the c library headers
You are right. uclibc does this:
#if 0 /* in uClibc we use macros */ extern cpu_set_t *__sched_cpualloc (size_t __count) __THROW __wur; extern void __sched_cpufree (cpu_set_t *__set) __THROW; #else # define __sched_cpualloc(cnt) ((cpu_set_t *)malloc(__CPU_ALLOC_SIZE(cnt)))
Ouch.
# define __sched_cpufree(__set) free(__set) #endif
And since this is only a warning, I don't think its worth the effort.
And that's where you're wrong. Using malloc() without a prototype means you are attempting to call 'int malloc(int)' instead of 'void *malloc(size_t)'; and if sizeof(size_t)>sizeof(int) (as on most 64-bit platforms), you have silently miscompiled. The warning exists for a reason, and we only have K&R C to blame that this is just a warning rather than a hard error by default (at least C++ did it right by mandating it as a hard error). -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Thu, 22 Nov 2012 06:53:12 -0700 Eric Blake <eblake@redhat.com> wrote:
On 11/22/2012 06:46 AM, Natanael Copa wrote:
If your headers are defining this in terms of malloc(), then IMHO, the sched.h should be including stdlib.h on our behalf. IOW, I think this is a bug in the c library headers
You are right. uclibc does this:
#if 0 /* in uClibc we use macros */ extern cpu_set_t *__sched_cpualloc (size_t __count) __THROW __wur; extern void __sched_cpufree (cpu_set_t *__set) __THROW; #else # define __sched_cpualloc(cnt) ((cpu_set_t *)malloc(__CPU_ALLOC_SIZE(cnt)))
Ouch.
# define __sched_cpufree(__set) free(__set) #endif
And since this is only a warning, I don't think its worth the effort.
And that's where you're wrong. Using malloc() without a prototype means you are attempting to call 'int malloc(int)' instead of 'void *malloc(size_t)'; and if sizeof(size_t)>sizeof(int) (as on most 64-bit platforms), you have silently miscompiled. The warning exists for a reason, and we only have K&R C to blame that this is just a warning rather than a hard error by default (at least C++ did it right by mandating it as a hard error).
You are of course right. I'll forward it to uclibc devs right away. Ugly thing. -nc
On 11/22/2012 06:36 AM, Daniel P. Berrange wrote:
util/processinfo.c: In function 'virProcessInfoSetAffinity': util/processinfo.c:52:5: error: implicit declaration of function 'malloc' [-Werror=implicit-function-declaration]
mask = CPU_ALLOC(numcpus);
On glibc this is defined to a function _sched_cpualloc(), hence we don't see a warning.
If your headers are defining this in terms of malloc(), then IMHO, the sched.h should be including stdlib.h on our behalf. IOW, I think this is a bug in the c library headers
That all said, I'm not against adding this workaround in libvirt, provided the c library bug is reported upstream.
Concur on both points. And I pushed the commit. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
participants (3)
-
Daniel P. Berrange -
Eric Blake -
Natanael Copa