Opened 18 years ago
Closed 14 years ago
#458 closed defect (invalid)
a fix for the numerous errors "differ in signedness" with GCC4 ?
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | normal | Component: | build system |
Version: | unspecified | Severity: | normal |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Reproduced by developer: | no | Analyzed by developer: | no |
Description
I found this interesting article http://forum.openvz.org/index.php?t=msg&goto=1265&
It may be usefull to correct the numerous errors "differ in signedness" when
compiling with GCC4.
Here I paste the content (the page may diseapper as well).
Hi,
today after building my openvz development environment i just wanted to
build the userspace tools like vzquota and vzctl. I tried to build
vzquota with the default Makefile and CFLAGS which includes '-Werror'
GCC4 complains about the following:
cc1: warnings being treated as errors
quotaon.c: In function 'quotaugidset_proc':
quotaon.c:1228: warning: pointer targets in passing argument 2 of 'str2uint'
differ in signedness
make[1]: * [quotaon.o] Error 1
Attached is a small fix which only changes the 'int ugid' (which is default
signed) to 'unsigned int ugid' Nothing more. :)
--Maik
diff -Nur vzquota-2.7.0-7/src/quotaon.c vzquota-2.7.0-7-signedness-fix/src/quotaon.c
--- vzquota-2.7.0-7/src/quotaon.c 2005-09-12 17:46:07.000000000 +0200
+++ vzquota-2.7.0-7-signedness-fix/src/quotaon.c 2006-02-04 16:37:30.233562250 +0100
@@ -1221,7 +1221,7 @@
quota_setugid(0, NULL, &info);
} else {
struct dq_stat stat;
- int ugid;
+ unsigned int ugid;
/* get ugid */
if (argc != 5
Attachments (2)
Change History (16)
comment:1 by , 18 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:2 by , 18 years ago
Resolution: | invalid |
---|---|
Status: | closed → reopened |
Okay people,
Here is a tree cleaned of (hopefully) every "warning: pointer targets in passing
argument * of '*' differ in signedness" when compiling on GCC4.
Tree took from CVS on 21 feb.
rather than a huge diff that may not be the best way to see what changes have
been done, I made 2 tgz files.
One with the original tree I got from CVS, one with the tree corrected.
So that you still can do diffs if you like.
get it at :
http://stranche.free.fr/mplayer-orig.tgz
http://stranche.free.fr/mplayer-cleaned.tgz
comment:3 by , 18 years ago
Owner: | changed from | to
---|---|
Status: | reopened → new |
Dominik, over to you, these are compiler warnings ...
comment:5 by , 18 years ago
comment:6 by , 18 years ago
Did I mention it should be a unified diff?
http://www.mplayerhq.hu/DOCS/tech/patches.txt
Besides, your patch contains unrelated changes, like:
diff -r main/config.mak main2/config.mak
76c76
< SRC_PATH=/home/stranche/test/main
---
SRC_PATH=/home/stranche/sauv-mplayer/main
diff -r main/DOCS/man/en/CVS/Entries main2/DOCS/man/en/CVS/Entries
1c1
< /mplayer.1/1.1231/Mon Feb 20 09:36:10 2006
---
/mplayer.1/1.1232/Mon Feb 20 23:50:40 2006
diff -r main/DOCS/man/en/mplayer.1 main2/DOCS/man/en/mplayer.1
1c1
< .\" $Revision: 1.1231 $
---
.\" $Revision: 1.1232 $
And so on. Please clean it up before sending it again.
by , 18 years ago
Attachment: | diff_mplayer.2.diff added |
---|
diff done with 'diff -Naur' and tested with 'patch -p0'
comment:7 by , 18 years ago
comment:8 by , 18 years ago
attachments.isobsolete: | 0 → 1 |
---|
comment:9 by , 18 years ago
Except maybe for a few select cases, this just makes the code ugly.
Disabling the warning would be the _much_ better solution IMHO.
comment:10 by , 18 years ago
I agree with Reimar. And since some of these touch libavcodec, I suggest posting
them to ffmpeg-devel. I think most of these casts won't be accepted, but those
hunks which change signed<->unsigned variables just might.
comment:11 by , 18 years ago
(In reply to comment #9)
Are you in contact directly with the ffmpeg people or should I propose the patch
myself ?
Anyway, I did all this to fix at least a part of the numerous warnings that made
the compilation ugly on GCC4, maybe it was not the most "clean" way to do but it
can give a few hints to make it right then.
After all, in GCC3 it is not reported at all but in GCC4 it is recognized, maybe
in the future such warning could become fatal.
comment:12 by , 18 years ago
(In reply to comment #8)
You mean using something like -Wno-sign-compare ?
comment:13 by , 14 years ago
Owner: | changed from | to
---|---|
Status: | assigned → new |
comment:14 by , 14 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Much of this no longer applies and/or is bogus.
Thanks for the hint, but we are aware of how to fix those warnings. If you wish
to see them gone, send a patch ...