"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes: | On 10 Jun 2006 20:07:02 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: | > I'll like to see a more precise definition of your understanding of | > "coercion" versus "conversion". Last time we dicussed this I was not | > quite clear about what you consider is "bad" what is not. | > I was under the impression you taught it was for "C" only, but you | > have to take into account that some warnings are shared with the C++ | > front-end and some of them really should be common to both front-ends. | > | > If your project is NOT about coercion in general, but those just | > related to function prototypes, you should be careful about the name | > of the option. Again, this assumes you tell us what you consider | > coercion and what you consider conversion. | > | > -- Gaby | > | | My project is about "risky" coercions in general: assignments, | operators, prototypes. You can see some (and comment and propose) | testcases in http://gcc.gnu.org/wiki/Wcoercion .
Thanks for maintaining a documentation about your current project. I hope by the time the project is completed the documentation becomes part of official GCC sources. People understand "conversion" because it is a term used in both C and C++ standards. You're introducing a second term (note : I did not say invented). You need to define it precisely so that people who have to give you feedback on work knows what you are talking about. Please do consider defining the term as you understand it and it guides your work. | I haven't thought how | all this works when you include classes and objects and inheritance. that is fine; once your have given clear definition and when you submit patches we will walk you through the implications. | However, this doesn't matter for this discussion because just taking | into account the current code in trunk, there are several problems : It does matter to know that they are implicit conversions that change values, and those are fine. It may be that in your definition, that is fine; but you have not told us precisely what it is. I'll like NOT to see a situation where you've spent months doing something that might be useful but we could not take it because you thought an aspect did not matter, when in fact it does. | 1) Following the documentation, currently Wconversion is used for two | different and unrelated things (i) "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" and (ii) "warn if a negative | integer constant expression is implicitly converted to an unsigned | type". These two behaviours should be split. Agrees. | 2) Currently, Wconversion works very different for C and for C++. I | have not seen anything in the manual explaining this, so I assume that | it is undocumented behaviour. I think this is bad: C and C++ should be | in sync and the current behaviour should be explained in the manual. if it is a documentation problem, the documentation should be strengthen instead of the option being removed. Note, "conversion" is a term well established in both C and C++ community. "coercion" is less used. And as a matter of fact, my understandings of terms are not the same. You need to nail it down. | 3) People using Wconversion to detect conversions that may be risky | are frequently told that this is not the intended purpose. However, in | g++, it currently works to some extent. People should not rely on | this. We should either warn them somehow that this is wrong or we | should fix Wconversion to do what they expect. However, fixing | Wconversion would silently break things for those that rely on its | original purpose. what kind of things that will be broken? If something is not documentation and we believe it is useful, we should document it. | So, I propose a third option: | | c) Remove Wconversion and create two new options Wcoercion and | Wprototypes-traditional. The reason is that both options (a) and (b) | would silently break Wconversion for someone. And keeping Wconversion | is not an option since it is currently broken and we need a way to Not just because you stated it is broken means it is. And even it is broken, please consider repair instead of removal. Please, do consider the above suggestions. -- Gaby
