Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
tintin++ ogg sound player script for linux
Author: Robert Smith
Submitted by: Vladaar
6Dragons ogg Soundpack
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.4
Author: Vladaar
Submitted by: Vladaar
LoP 1.46
Author: Remcon
Submitted by: Remcon
LOP 1.45
Author: Remcon
Submitted by: Remcon
Users Online
CommonCrawl, Remcon, Google

Members: 1
Guests: 15
Stats
Files
Topics
Posts
Members
Newest Member
481
3,734
19,364
618
Micheal64X
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » General » Coding » -Wconversion compiler flag
Forum Rules | Mark all | Recent Posts

-Wconversion compiler flag
< Newer Topic :: Older Topic > DIE DIE DIE DIE!

Pages:<< prev 1 next >>
Post is unread #1 Oct 5, 2008, 6:00 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

A heads up for those of you migrating over to GCC 4.3. The -Wconversion flag that's been hanging around Makefiles for awhile now and seemingly doing nothing has suddenly spring to life. If you start seeing warnings/errors like this one:
character.h: In member function 'void char_data::WAIT_STATE(int)':
character.h:461: error: conversion to 'short int' from 'int' may alter its value


then your Makefile likely has the flag in it. It may or may not be a legitimate beef. To me it's more of an annoyance than a real help since trying to fix it leads down a really deep dark rabbit hole where you'll spend days or weeks trying to silence it all. Your time is better spent on fixing the "real" errors that 4.3 is introducing, if any.
       
Post is unread #2 Oct 5, 2008, 8:05 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

It could be a legitimate error message. If you have a value in an int that is larger than the range for short ints, and you're doing a conversion, then you will be losing the value. Such conversions should always be made explicitly, to note that the programmer has looked at and "approved" the conversion, instead of implicitly. Sure, it's annoying, but, well, that's what happens when people do things this way...
       
Post is unread #3 Oct 5, 2008, 8:18 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

Generally I would agree, except when I tried to explicitly cast the warnings away, they didn't go away. I'm not about to cook up some kind of crazy scheme to dodge it when it's not even a default warning flag and hasn't been a thorn up until 4.3 :)
       
Post is unread #4 Oct 5, 2008, 8:20 pm   Last edited Oct 5, 2008, 8:21 pm by David Haley
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Wouldn't a C++-style cast like static_cast or reinterpret_cast fix it?

EDIT: I don't remember which it is, I think it's reinterpret, but it basically tells the compiler that you really mean it when you do a non-standard conversion like that. g++ seems to accept c++-style casts more than the c-style casts.
       
Post is unread #5 Oct 5, 2008, 8:26 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

Uh. I suppose that might work, but I've never done anything with static_cast or reinterpret_cast. How would you use them in this situation?
       
Post is unread #6 Oct 6, 2008, 7:00 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

You would do something like:

int i;
short s;
...
s = reinterpret_cast<short>(i);
       
Post is unread #7 Oct 11, 2008, 1:55 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

GCC Release Notes said:

The -Wconversion option has been modified. Its purpose now is to warn for implicit conversions that may alter a value. This new behavior is available for both C and C++. Warnings about conversions between signed and unsigned integers can be disabled by using -Wno-sign-conversion. In C++, they are disabled by default unless -Wsign-conversion is explicitly requested. The old behavior of -Wconversion, that is, warn for prototypes causing a type conversion that is different from what would happen to the same argument in the absence of a prototype, has been moved to a new option -Wtraditional-conversion, which is only available for C.


I suppose we have an explanation as to why the behavior suddenly changed. Because, well, it did. Now, I'm sure arguing the point is useless, but doesn't this sort of thing deserve more notice? And shouldn't they have created a new flag instead of changing the behavior of an existing one? Ah well. Either way the new behavior is not desirable for use unless one is terribly bored and has nothing else to do :)
       
Post is unread #8 Oct 11, 2008, 7:14 pm   Last edited Oct 11, 2008, 7:16 pm by Caius
Go to the top of the page
Go to the bottom of the page

Caius
Magician
GroupMembers
Posts132
JoinedJan 29, 2006

Here's a real kicker. Try this little program with the -Wconversion flag on gcc 4.3:

int main()
{
  short x = 1;
  short y = 2;
  x += y;
}

The compiler will complain that you're trying to convert a short int to an int, even though they are both shortS! Apparently operators like += will promote the values to int implicitly. From what I've been told this is supposed to be correct behaviour, but it seems rather odd to me. Not even casting the rvalue will help. I believe the only thing you can do now is to either remove the -Wconversion flag, or the -Werror flag and live with the warning. Really annoying.
       
Post is unread #9 Oct 11, 2008, 8:18 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

I agree that it should have had more notice, and I also agree that it's of dubious utility to modify the existing behavior rather than adding a new flag. But I really disagree that the behavior is useless in general, because people should really not be casting integer sizes willy-nilly.

Now, as for what Caius posted, it is pretty messed up that that fails. (Are you sure that the error comes from the +=, and it's not trying to return that value or something like that? What if you put return 0 at the end?)
       
Post is unread #10 Oct 11, 2008, 8:31 pm   Last edited Oct 11, 2008, 8:31 pm by Caius
Go to the top of the page
Go to the bottom of the page

Caius
Magician
GroupMembers
Posts132
JoinedJan 29, 2006

DavidHaley said:

Now, as for what Caius posted, it is pretty messed up that that fails. (Are you sure that the error comes from the +=, and it's not trying to return that value or something like that? What if you put return 0 at the end?)

Adding a 'return 0' at the end makes no difference. When I first ran into this I did a Google, and I'm certainly not the first person to have stumbled onto this.

Check out this thread for more on the subject.
       
Post is unread #11 Oct 11, 2008, 9:22 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

It's complaining about returning an int when all the variables inside are shorts. Which I think is ludicrous, and I don't care how "correct" it seems, in practice it's just a colossal waste of time. And yes, even more of a waste of developer time than the const issue was. Because at least the const issue had some glimmer of an argument for correctness. This though, this is stupider than using -pedantic.
       
Post is unread #12 Oct 11, 2008, 11:54 pm
Go to the top of the page
Go to the bottom of the page

Keberus
Conjurer
GroupFUSS Project Team
Posts341
JoinedJun 4, 2005


Caius said:

Here's a real kicker. Try this little program with the -Wconversion flag on gcc 4.3:

int main()
{
  short x = 1;
  short y = 2;
  x += y;
}

The compiler will complain that you're trying to convert a short int to an int, even though they are both shortS! Apparently operators like += will promote the values to int implicitly. From what I've been told this is supposed to be correct behaviour, but it seems rather odd to me. Not even casting the rvalue will help. I believe the only thing you can do now is to either remove the -Wconversion flag, or the -Werror flag and live with the warning. Really annoying.


Sounds like the += is meant for integers instead of shorts, maybe (at least if you're compiling with C++ ) you could overload the += operator. Not sure how to do it myself, but I am pretty sure it can be done.


Samson said:

It's complaining about returning an int when all the variables inside are shorts. Which I think is ludicrous, and I don't care how "correct" it seems, in practice it's just a colossal waste of time. And yes, even more of a waste of developer time than the const issue was. Because at least the const issue had some glimmer of an argument for correctness. This though, this is stupider than using -pedantic.


You make me laugh sometimes, Samson.
       
Post is unread #13 Oct 12, 2008, 1:11 am
Go to the top of the page
Go to the bottom of the page

Caius
Magician
GroupMembers
Posts132
JoinedJan 29, 2006

Keberus said:

Sounds like the += is meant for integers instead of shorts, maybe (at least if you're compiling with C++ ) you could overload the += operator. Not sure how to do it myself, but I am pretty sure it can be done.

You can't overload the operators for fundamental types. Fortunately. Think of all the confusion and obscurity that could potentially introduce. You include a 3rd party header file, but they have changed the operator behaviour of intS and other fundamental types! Would probably take a long while to figure out why the program doesn't behave as expected. So while it may have been handy in this particular case, it's definitely a good thing that the compiler won't let you do it.
       
Post is unread #14 Oct 12, 2008, 5:22 pm
Go to the top of the page
Go to the bottom of the page

Keberus
Conjurer
GroupFUSS Project Team
Posts341
JoinedJun 4, 2005

My bad, but you can overload? Just user created types?
       
Post is unread #15 Oct 12, 2008, 6:51 pm   Last edited Oct 12, 2008, 6:53 pm by Caius
Go to the top of the page
Go to the bottom of the page

Caius
Magician
GroupMembers
Posts132
JoinedJan 29, 2006

Yes, you can overload operators for user-defined types/classes. You can also overload how your types works with fundamental types. For example, say you're making a class called HugeInteger that can hold astronomical numbers. You can then overload its operators such that you can use it with intS and shortS and such:

HugeInteger x = 10000000000000000000000000;
int y = 4567;
x += y; // x == 10000000000000000000004567

So you can overload your own types, how they work with eachother, and how they work with fundamental types. But you can not alter the normal behaviour of the latter.
       
Post is unread #16 Oct 12, 2008, 10:44 pm
Go to the top of the page
Go to the bottom of the page

Keberus
Conjurer
GroupFUSS Project Team
Posts341
JoinedJun 4, 2005


Caius said:

Yes, you can overload operators for user-defined types/classes. You can also overload how your types works with fundamental types. For example, say you're making a class called HugeInteger that can hold astronomical numbers. You can then overload its operators such that you can use it with intS and shortS and such:

HugeInteger x = 10000000000000000000000000;
int y = 4567;
x += y; // x == 10000000000000000000004567

So you can overload your own types, how they work with eachother, and how they work with fundamental types. But you can not alter the normal behaviour of the latter.


Ok, thanks for the info.
       
Post is unread #17 Oct 13, 2008, 9:52 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Samson said:

It's complaining about returning an int when all the variables inside are shorts. Which I think is ludicrous, and I don't care how "correct" it seems, in practice it's just a colossal waste of time. And yes, even more of a waste of developer time than the const issue was. Because at least the const issue had some glimmer of an argument for correctness. This though, this is stupider than using -pedantic.

This particular instance sounds like a bug, or a "feature" of how += works. It's pretty different from the general case of actually trying to convert an int to a short implicitly.
       
Pages:<< prev 1 next >>