Hi guys, The following snippet of code should not produce a warning as far as I understand: int foo(short bar) { return bar; } int main() { short d = 0; return foo(d); } Unfortunately, however, I get this when I try to compile this code: jkroon@pitchblack ~/src $ gcc -Wconversion -o foo foo.c foo.c: In function 'main': foo.c:9: warning: passing argument 1 of 'foo' with different width due to prototype jkroon@pitchblack ~/src $ We use -Wconversion to catch assignments of signed values to unsigned variables like such: unsigned foo = -1; Which it catches correctly as expected. This problem also shows up when using char instead of short (at least, haven't tested other types). If the type of bar gets changed to int in the parameter list of foo the warning goes away. This warning was orriginally noted when using the strtok_r function, which uses a macro implementation in order to use more optimal variations for certain cases, the branch that checks for a constant needle of length 1 and then uses a variation that looks for a single char produces the same warning: warning: passing argument 2 of '__strtok_r_1c' with different width due to prototype
The warning works as intended. *** This bug has been marked as a duplicate of 6614 ***
(a bit more explanation won't hurt) The GCC documentation says: -Wconversion: Warn if a prototype causes a type conversion that is different from what would happen to the same argument in the absence of a prototype. In your program, in the absence of prototype, d would be promoted to int, thus the warning is correct. Wconversion is only useful for translating very old C code to ANSI/ISO C. Since this behaviour is not very useful in the present day, and Wconversion also warns for unsigned i = -1, we are going to move the above behaviour to Wtraditional-conversion and make Wconversion warn for implicit conversions that may change a value. This is planned for GCC 4.3 . For more info, please check http://gcc.gnu.org/wiki/Wcoercion and don't hesitate to contact me. (That wiki page is work in progress, not definitive, actually, it is a bit outdated). Testing and comments are welcome.
Awesome. That would be a good move. The implicit conversions are very handy for catching certain types of bugs early one, however, the function prototype thing is a pain. Unfortunately I won't be able to assist with testing etc in this regard, but I need to say that I truly appreciate the quick response to my bug reports (both here, and in general). You guys are doing awesome work. Keep it up.
Quick response? you must be joking. I reported this in "Opened: 2002-05-09 14:46" against 2.95.3.
I'm refering to the response to the bug, not the actual fix. I've had the "priviledge" of filing bugs against other projects where I forgot about the bug by the time somebody responded (two years down the line). I reckon having an explanation of what is going in in less that 5 hours is good.
4 years to agree there is an issue here. maybe we will have a fix in 2010.
I think 4.3 will be released on 2007 or early 2008. Fixing bugs on 4.2 and 4.3 will speed up things, of course. In addition, anyone could take the patches and apply them to their preferred stable version. I think they will apply more or less cleanly to any 4.X version. On the other hand, there is no issue at all in the sense that Wconversion works as documented and it was probably very useful when it was implemented. Now, the desire for a "different" Wconversion has been acknowledged by GCC developers since a long long time ago and they would have welcomed any implementation the very same day that you opened your bug. Just nobody (not only GCC devs, I mean no person on earth, not even you) had enough free time, resources or interest to implement it or they had higher priorities. Finally, I understand your frustration. I have done the same when I have been frustrated with software. (I may still do it sometimes without being fully aware and I always regret it) But I have learnt that negative comments (such as #6) are pointless, on the contrary, they tend to hurt and offend developers that have put endless nights, tears and blood on it. Even if you are completely right and correct, offending someone before asking for a favour simply doesn't work.
I spent a considerable amount of my personal time on open source projects, so I am not particularily ashamed of not fixing this bug myself (I tried, but gave up after I realized the learnign curve is too steep). I consider gcc to be one of the most important open source projects there is, as it is a prerequiste for most other projects, and greatly appreciate everyone contributing to this monumental project. However, unless the situation has dramatically changed, given the state of gcc code only the most determined non-maintainer would be able to fix bugs/problems. This probably explains my personal dismay regarding the fate of my bug reports.