debian jessie c compiler complains about these in kamailio 4.4:
CC (gcc) [sip-proxy] mem/tlsf_malloc.o mem/tlsf_malloc.c: In function 'tlsf_malloc_init_pkg_manager': mem/tlsf_malloc.c:1353:16: warning: assignment from incompatible pointer type ma.xmalloc = tlsf_malloc; ^ mem/tlsf_malloc.c:1355:16: warning: assignment from incompatible pointer type ma.xrealloc = tlsf_realloc; ^ mem/tlsf_malloc.c:1358:16: warning: assignment from incompatible pointer type ma.xavailable = tlsf_available; ^ mem/tlsf_malloc.c: In function 'tlsf_malloc_init_shm_manager': mem/tlsf_malloc.c:1501:20: warning: assignment from incompatible pointer type ma.xmalloc_unsafe = tlsf_malloc; ^ it would be highly appreciated to get rid of them.
-- juha
I have not got any comments about getting rid of 4.4 compiler warnings in mem/tlsf_malloc.c.
I'm afraid that if such warnings are tolerated, it will soon be difficult to distinguish real problems from all the warning noise during.
In my opinion, a sign of high quality software project is that no warnings are produced during compilation. Baresip is an excellent example of that.
-- Juha
Hello Juha,
we try to address the warnings as soon as possible, but sometime is a matter of resources. The author of the tlsf code is Camille, which may have some vacation, be traveling or really busy with other things -- it is less than one day since you reported. Also, others may not have immediately access to the OS distro you reported issues for. E.g., I didn't have the time anyhow, but I don't get those warning using clang on my devel system.
On the other hand, you can push patches fixing those warnings, in case you can assert the fix. It is an open source collaborative project, it is not necessary to wait for the initial developer to fix something that you consider to be important. The master branch is open for everyone and it is not hard to revert if one developer has amendments or something against a patch.
Cheers, Daniel
On 11/05/16 13:58, Juha Heinanen wrote:
I have not got any comments about getting rid of 4.4 compiler warnings in mem/tlsf_malloc.c.
I'm afraid that if such warnings are tolerated, it will soon be difficult to distinguish real problems from all the warning noise during.
In my opinion, a sign of high quality software project is that no warnings are produced during compilation. Baresip is an excellent example of that.
-- Juha
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Daniel-Constantin Mierla writes:
we try to address the warnings as soon as possible, but sometime is a matter of resources. The author of the tlsf code is Camille, which may have some vacation, be traveling or really busy with other things -- it is less than one day since you reported. Also, others may not have immediately access to the OS distro you reported issues for. E.g., I didn't have the time anyhow, but I don't get those warning using clang on my devel system.
i'm not any c expert, but perhaps the first warning
mem/tlsf_malloc.c: In function 'tlsf_malloc_init_pkg_manager': mem/tlsf_malloc.c:1353:16: warning: assignment from incompatible pointer type ma.xmalloc = tlsf_malloc;
is issued or not depending on your DBG_TLSF_MALLOC value:
#ifdef DBG_TLSF_MALLOC void* tlsf_malloc(tlsf_t tlsf, size_t size, const char *file, const char *function, unsigned int line, const char *mname) #else void* tlsf_malloc(tlsf_t tlsf, size_t size) #endif
looks like the types match if DBG_TLSF_MALLOC is defined and don't match otherwise.
-- juha
debian jessie c compiler complains about these in kamailio 4.4:
CC (gcc) [sip-proxy] mem/tlsf_malloc.o mem/tlsf_malloc.c: In function 'tlsf_malloc_init_pkg_manager': mem/tlsf_malloc.c:1353:16: warning: assignment from incompatible pointer type ma.xmalloc = tlsf_malloc;
Hi,
is this happening on a x86 32 bits machine? This issue was pointed out already by Ovidu Sas: http://lists.sip-router.org/pipermail/sr-dev/2016-January/thread.html#32757, but I had no 32 bits machine to test this on, and also no idea why it does not work (I see no error message on my 64 bits Debian Jessie).
All I see is that we are assigning a void* (*)(tlsf_t, size_t) to a void* (*)(void* , unsigned long) yet tlsf_t is defined as `typedef void* tlsf_t`, and size_t and unsigned long have the same width on this architecture...
Do compiling with clang generates an error too? If yes, is the error message more specific about the issue?
Any other idea?
-- Camille
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
If you have a patch, I can test it for you.
-ovidiu On May 11, 2016 10:56, camille.oudot@orange.com wrote:
debian jessie c compiler complains about these in kamailio 4.4:
CC (gcc) [sip-proxy] mem/tlsf_malloc.o mem/tlsf_malloc.c: In function 'tlsf_malloc_init_pkg_manager': mem/tlsf_malloc.c:1353:16: warning: assignment from incompatible pointer
type
ma.xmalloc = tlsf_malloc;
Hi,
is this happening on a x86 32 bits machine? This issue was pointed out already by Ovidu Sas: < http://lists.sip-router.org/pipermail/sr-dev/2016-January/thread.html#32757
,
but I had no 32 bits machine to test this on, and also no idea why it does not work (I see no error message on my 64 bits Debian Jessie).
All I see is that we are assigning a void* (*)(tlsf_t, size_t) to a void* (*)(void* , unsigned long) yet tlsf_t is defined as `typedef void* tlsf_t`, and size_t and unsigned long have the same width on this architecture...
Do compiling with clang generates an error too? If yes, is the error message more specific about the issue?
Any other idea?
-- Camille
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
camille.oudot@orange.com writes:
All I see is that we are assigning a void* (*)(tlsf_t, size_t) to a void* (*)(void* , unsigned long) yet tlsf_t is defined as `typedef void* tlsf_t`, and size_t and unsigned long have the same width on this architecture...
Is that true also when DBG_TLSF_MALLOC has been defined?
-- Juha
Hi,
All I see is that we are assigning a void* (*)(tlsf_t, size_t) to a void* (*)(void* , unsigned long) yet tlsf_t is defined as `typedef void* tlsf_t`, and size_t and unsigned long have the same width on this architecture...
Is that true also when DBG_TLSF_MALLOC has been defined?
DBG_TLSF_MALLOC is defined if DBG_SR_MEMORY is defined (mem/tlsf_malloc.h:25) , so in this case it assigns a
void* (*)(tlsf_t, size_t, const char*, const char*, unsigned int, const char*)
to a
void* (*)(void*, unsigned long, const char*, const char*, unsigned int, const char*)
I'm also compiling on Debian 8, x86_64-linux-gnu architecture, but cannot see these warnings, whether I run
make MEMDBG=0 cfg
or
make MEMDBG=1 cfg
before compiling. My gcc version is 4.9.2 (Debian 4.9.2-10).
Camille Oudot writes:
I'm also compiling on Debian 8, x86_64-linux-gnu architecture, but cannot see these warnings, whether I run
make MEMDBG=0 cfgor
make MEMDBG=1 cfgbefore compiling. My gcc version is 4.9.2 (Debian 4.9.2-10).
I have the same. Perhaps it has to do with some other defines. Do you remember what to add to debian/rules in order to see all gcc parameters during compilation?
-- JUha
Juha Heinanen writes:
I have the same. Perhaps it has to do with some other defines. Do you remember what to add to debian/rules in order to see all gcc parameters during compilation?
I did 'apt-get dist-upgrade'. The following packages were upgraded and the mem/tlsf_malloc.c warnings went away:
apt apt-utils base-files gnupg gpgv libapt-inst1.5 libapt-pkg4.12 libc-bin libc-dev-bin libc6 libc6-dev libcurl3 libcurl4-openssl-dev libgcrypt20 libglib2.0-0 libglib2.0-bin libglib2.0-dev libgssapi-krb5-2 libhogweed2 libk5crypto3 libkrb5-3 libkrb5support0 libmysqlclient-dev libmysqlclient18 libnettle4 libpam-modules libpam-modules-bin libpam0g libpcre3 libpcre3-dev libpcrecpp0 libssh2-1 libssl-dev libssl1.0.0 libsystemd0 libtiff5 libtiff5-dev libtiffxx5 libudev1 linux-libc-dev multiarch-support mysql-common openssl perl perl-base perl-modules systemd systemd-sysv tzdata udev
Sorry about the noise. Now the once below (plus tls module ones) remain. They appeared already before 4.4.
-- Juha
CC (gcc) [sip-proxy] cfg/cfg_ctx.o cfg/cfg_ctx.c: In function 'cfg_set_now': cfg/cfg_ctx.c:485:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] group_inst = (cfg_group_inst_t *)translate_pointer((char *)new_array, ^ cfg/cfg_ctx.c:489:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] CFG_GROUP_META(block, group)->array = new_array; ^ cfg/cfg_ctx.c:559:4: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] if (block && (CFG_GROUP_META(block, group)->array != CFG_GROUP_META(*cfg_global, group)->array)) ^ cfg/cfg_ctx.c:559:4: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] cfg/cfg_ctx.c:560:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] new_array = CFG_GROUP_META(block, group)->array; ^ cfg/cfg_ctx.c:579:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] replaced[i] = CFG_GROUP_META(*cfg_global, group)->array; ^ cfg/cfg_ctx.c: In function 'cfg_commit': cfg/cfg_ctx.c:1120:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] if (!(CFG_GROUP_META(block, group)->array = ^ cfg/cfg_ctx.c:1128:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] replaced[replaced_num] = CFG_GROUP_META(*cfg_global, group)->array; ^ cfg/cfg_ctx.c:1180:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] && (CFG_GROUP_META(block, changed->group)->array != CFG_GROUP_META(*cfg_global, changed->group)->array) ^ cfg/cfg_ctx.c:1180:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] cfg/cfg_ctx.c:1185:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] replaced[replaced_num] = CFG_GROUP_META(*cfg_global, group)->array; ^ cfg/cfg_ctx.c:1220:4: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] if (CFG_GROUP_META(block, group)->array ^ cfg/cfg_ctx.c:1221:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] && (CFG_GROUP_META(block, group)->array != CFG_GROUP_META(*cfg_global, group)->array) ^ cfg/cfg_ctx.c:1221:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] cfg/cfg_ctx.c:1223:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] shm_free(CFG_GROUP_META(block, group)->array); ^ cfg/cfg_ctx.c: In function 'cfg_add_group_inst': cfg/cfg_ctx.c:1577:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] CFG_GROUP_META(block, group)->array = new_array; ^ cfg/cfg_ctx.c:1578:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] CFG_GROUP_META(block, group)->num++; ^ cfg/cfg_ctx.c:1580:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] if (CFG_GROUP_META(*cfg_global, group)->array) { ^ cfg/cfg_ctx.c:1589:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] replaced[0] = CFG_GROUP_META(*cfg_global, group)->array; ^ cfg/cfg_ctx.c: In function 'cfg_del_group_inst': cfg/cfg_ctx.c:1673:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] CFG_GROUP_META(block, group)->array = new_array; ^ cfg/cfg_ctx.c:1674:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] CFG_GROUP_META(block, group)->num--; ^ cfg/cfg_ctx.c:1676:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] if (CFG_GROUP_META(*cfg_global, group)->array) { ^ cfg/cfg_ctx.c:1687:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] && (*(char **)(group_inst->vars + var->offset) != NULL) ^ cfg/cfg_ctx.c:1705:6: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] && (*(char **)(group_inst->vars + var->offset) != NULL) ^ cfg/cfg_ctx.c:1707:6: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] replaced[num] = *(char **)(group_inst->vars + var->offset); ^ cfg/cfg_ctx.c:1713:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] replaced[num] = CFG_GROUP_META(*cfg_global, group)->array; ^
Le Thu, 12 May 2016 12:30:15 +0300, Juha Heinanen jh@tutpro.com a écrit :
I did 'apt-get dist-upgrade'. The following packages were upgraded and the mem/tlsf_malloc.c warnings went away:
apt apt-utils base-files gnupg gpgv libapt-inst1.5 libapt-pkg4.12 libc-bin libc-dev-bin libc6 libc6-dev libcurl3 libcurl4-openssl-dev libgcrypt20 libglib2.0-0 libglib2.0-bin libglib2.0-dev libgssapi-krb5-2 libhogweed2 libk5crypto3 libkrb5-3 libkrb5support0 libmysqlclient-dev libmysqlclient18 libnettle4 libpam-modules libpam-modules-bin libpam0g libpcre3 libpcre3-dev libpcrecpp0 libssh2-1 libssl-dev libssl1.0.0 libsystemd0 libtiff5 libtiff5-dev libtiffxx5 libudev1 linux-libc-dev multiarch-support mysql-common openssl perl perl-base perl-modules systemd systemd-sysv tzdata udev
Thanks for the info, maybe something to do with the update of linux-libc-dev?
Le Thu, 12 May 2016 12:03:59 +0300, Juha Heinanen jh@tutpro.com a écrit :
Perhaps it has to do with some other defines. Do you remember what to add to debian/rules in order to see all gcc parameters during compilation?
I add "Q=0" on the make command line to see the full compiler's command line. For the specific case of the tlsf_malloc.c compilation, with MEMDBG previously configured to 1, it shows:
gcc -g -funroll-loops -Wcast-align -m64 -minline-all-stringops -falign-loops -ftree-vectorize -fno-strict-overflow -Wall -DNAME='"kamailio"' -DVERSION='"5.0.0-dev4"' -DARCH='"x86_64"' -DOS='linux_' -DOS_QUOTED='"linux"' -DCOMPILER='"gcc 4.9.2"' -D__CPU_x86_64 -D__OS_linux -DSER_VER=5000000 -DCFG_DIR='"/usr/local/etc/kamailio/"' -DRUN_DIR='"/var/run/kamailio/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DDNS_IP_HACK -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DUSE_DNS_CACHE -DUSE_DNS_FAILOVER -DUSE_DST_BLACKLIST -DUSE_NAPTR -DWITH_XAVP -DMEM_JOIN_FREE -DF_MALLOC -DQ_MALLOC -DTLSF_MALLOC -DDBG_SR_MEMORY -DUSE_TLS -DTLS_HOOKS -DUSE_CORE_STATS -DSTATISTICS -DMALLOC_STATS -DWITH_AS_SUPPORT -DUSE_SCTP -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DCC_GCC_LIKE_ASM -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_SCHED_SETSCHEDULER -DUSE_RAW_SOCKS -DHAVE_EPOLL -DHAVE_SIGIO_RT -DSIGINFO64_WORKARROUND -DUSE_FUTEX -DHAVE_SELECT -c mem/tlsf_malloc.c -o mem/tlsf_malloc.o -MMD -MP
and no warning on my machine.
-
Camille Oudot -
camille.oudot＠orange.com
-
Daniel-Constantin Mierla -
Juha Heinanen -
Ovidiu Sas