06 Oct, 2008, Guest wrote in the 1st comment:
Votes: 0
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:
Quote
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.
06 Oct, 2008, David Haley wrote in the 2nd comment:
Votes: 0
Sorry for double-posting, but since my first reply was to SmaugMUDs and the audience here is slightly bigger I'll post again:
Quote
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…
06 Oct, 2008, quixadhal wrote in the 3rd comment:
Votes: 0
Actually, that's on my "not-so-short" list of things that don't need to be done that way since my computer has more RAM than our old MUD boxes had hard disk space. Namely, replacing all short ints with normal 32-bit ints.

Yeah, it wastes space, but how many man-hours have been spent fixing bugs where n > 32767, or 65535 because in days of yore, it made the difference between the sys-admin telling you to stop running the mud on the campus mail server? Just look at the plethora of "2 billion vnum" patches across ALL the diku variants.

Besides, your compiler may be padding your structures to 4-byte boundaries anyways….

Keep the short ints for mud.c64.org, where they're useful. :)
06 Oct, 2008, Guest wrote in the 4th comment:
Votes: 0
Shorts aren't the only complaints it's giving though. Everything from short, int, float, size_t, ssize_t, long, unsigned long, unsigned short, you name it. It would take a lot more than just eliminating the use of shorts. Honestly I don't see this one as enough of a bother to leave the flag in place unless one is really REALLY board for some reason.
06 Oct, 2008, David Haley wrote in the 5th comment:
Votes: 0
I think it's complaining about any conversion from a type with a larger range to a type with a smaller range, or a conversion from signedness to unsignedness. In other words, it's not letting people get away with any implicit conversion that could cause data loss.
06 Oct, 2008, MacGregor wrote in the 6th comment:
Votes: 0
quixadhal said:
Actually, that's on my "not-so-short" list of things that don't need to be done that way since my computer has more RAM than our old MUD boxes had hard disk space. Namely, replacing all short ints with normal 32-bit ints.

Yeah, it wastes space, but how many man-hours have been spent fixing bugs where n > 32767, or 65535 because in days of yore, it made the difference between the sys-admin telling you to stop running the mud on the campus mail server? Just look at the plethora of "2 billion vnum" patches across ALL the diku variants.

Besides, your compiler may be padding your structures to 4-byte boundaries anyways….

Keep the short ints for mud.c64.org, where they're useful. :)

Speaking of short (16-bit) ints, they don't save as much space as you might think, at least not on Intel and compatible processors, and in some cases they actually take more space. The issue is every instruction that references a 16-bit datum has an extra prefix byte (and on 386's, 486's and early Pentiums at least, required an extra clock cycle to execute, to boot). Consider that normally you need at least one instruction to assign a variable and at least one instruction to reference it (else the variable is pointless), and in many cases it's a break-even at best. For this reason, I stopped using short ints in my code a long time ago.
06 Oct, 2008, David Haley wrote in the 7th comment:
Votes: 0
I think that's a pretty different issue than memory usage on the heap. Presumably, for enough data, where "enough" isn't really that big, memory used on the heap far surpasses memory used by the code.
06 Oct, 2008, MacGregor wrote in the 8th comment:
Votes: 0
More often than not you're right, but not always; I'm just saying it's not always the automatic savings or at least no loss that people think it is.

d->connected would be an example, unless you've got a very busy mud.
07 Oct, 2008, David Haley wrote in the 9th comment:
Votes: 0
Fair enough; if a given short is only used a few times but accessed in very many places then I agree that what you described could have start to have quite an effect. (I'm still not convinced it would be large enough to really matter, but it's good to know. It'd be nice to see actual numbers on the issue.)
0.0/9