18 Feb, 2008, Kline wrote in the 1st comment:
Votes: 0
So this is a first for me, ever. sprintf seems to be mis-behaving and I'm at a total loss to what could be causing this :(

The offending code:
act2("$D",ch,NULL,NULL,TO_CHAR,statcap);
statcap = 54321;
sprintf(buf,"You have %d experience points and a %d statcap.\n\r",ch->exp,statcap);
stc(buf,ch);
act2("$D",ch,NULL,NULL,TO_CHAR,statcap);


Actual output in-game:
30125
You have 151547 experience points and a 0 statcap.
54321


This is the only place in my code where things just aren't working as they should be with something as simple as sprintf. The first 30125 outputted is a correct value but the sprintf() always sends a 0. I've previously run memtest86 on my box for a day and it came back clean, so I'm not sure where to head from here…
18 Feb, 2008, Tommi wrote in the 2nd comment:
Votes: 0
int statcap = 54321;
sprintf(buf,"You have %d experience points and a %d statcap.\n\r",ch->exp,statcap);
send_to_char(buf,ch);


You have 0 experience points and a 54321 statcap.


Works for me, i don't really know whats going on.
18 Feb, 2008, Zeno wrote in the 3rd comment:
Votes: 0
What is statcap, an int?
18 Feb, 2008, Kline wrote in the 4th comment:
Votes: 0
Yeah, just an int defined further up the function.
19 Feb, 2008, Zeno wrote in the 5th comment:
Votes: 0
Have you tried this in other functions?

Have you tried this in a brand new c file with a new exec (nothing to do with the MUD)?
19 Feb, 2008, Guest wrote in the 6th comment:
Votes: 0
Would you mind pasting the entire function this came from, if possible? I see nothing from your mini-snippet there that should be causing this, but maybe someone can spot something from the larger context.
19 Feb, 2008, drrck wrote in the 7th comment:
Votes: 0
My initial guess, without seeing your declaration of statcap, is that you used a signed short integer (usually 16-bit). This data type has a range of approximately -32k to +32k, and 54321 would exceed the data type. To fix it, you should either change it to a normal, 32-bit integer (-2mil to +2mil), or specify that the variable is unsigned (0 to +65k).

Of course, if your expected value for the variable is always going to be within the signed short integer data range, maybe you should just use a more suitable test value.
19 Feb, 2008, David Haley wrote in the 8th comment:
Votes: 0
An overflow wouldn't cause the value to be zero; it would make it some negative number.

Kline, have you tried running valgrind? Maybe you're messing up your stack somewhere…
19 Feb, 2008, drrck wrote in the 9th comment:
Votes: 0
DavidHaley said:
An overflow wouldn't cause the value to be zero; it would make it some negative number.

Kline, have you tried running valgrind? Maybe you're messing up your stack somewhere…


An overflow could very well cause it to be zero. It may not be likely, due to 54321 not lying on a type range boundary, but overflow behavior is platform dependent.

I didn't notice his act2() calls until now, though, which makes it impossible for this to be the case here anyway.
20 Feb, 2008, David Haley wrote in the 10th comment:
Votes: 0
It is very, very, very unlikely that he is on a platform where the number 54321 would cause the number to be zero. The vast majority of machine architectures and compilers (in fact, every single one that I know of, and I know several) simply drop the extra bits or store them in an overflow register (the end result being the same as far as the variable is concerned). 54321 in binary is 1101010000110001. No matter whether your system is big-endian, or little-endian, twos-complement or signed-bit, you will not end up with a zero value.

So in conclusion, no, an overflow is really not at all likely to be the source of the problem here. :smile: (The act2 call simply rubs that in.)
20 Feb, 2008, drrck wrote in the 11th comment:
Votes: 0
DavidHaley said:
It is very, very, very unlikely that he is on a platform where the number 54321 would cause the number to be zero. The vast majority of machine architectures and compilers (in fact, every single one that I know of, and I know several) simply drop the extra bits or store them in an overflow register (the end result being the same as far as the variable is concerned). 54321 in binary is 1101010000110001. No matter whether your system is big-endian, or little-endian, twos-complement or signed-bit, you will not end up with a zero value.

So in conclusion, no, an overflow is really not at all likely to be the source of the problem here. :smile: (The act2 call simply rubs that in.)


There are implementations that will produce a zero on overflow/underflow no matter what numbers are involved, with an overflow bit. I never said it was likely (it's definitely not) - just possible. Personally, I can't think of a "likely" reason for the behavior his program is exhibiting, though.

Kline, if you haven't figured it out yet, try reversing the sprintf() arguments.
20 Feb, 2008, David Haley wrote in the 12th comment:
Votes: 0
I'd be curious to hear what implementation you're talking about, and how many computers (that people would have access to in this context) run it…

Another thing to try is printing it several times in a row, since it appears to be working with act2. Try using normal printf and look at the output to the console. Try setting a breakpoint in gdb and see what happens to the number as you step through the code.
20 Feb, 2008, drrck wrote in the 13th comment:
Votes: 0
DavidHaley said:
I'd be curious to hear what implementation you're talking about, and how many computers (that people would have access to in this context) run it…


Apparently not curious enough to Google ;)
20 Feb, 2008, David Haley wrote in the 14th comment:
Votes: 0
I already said that the architectures I know of that the kind of people running MUD servers would have access to do not have the behavior you describe… surely, since you know of all these architectures, it would take you just a moment to give me just one little name of a common architecture that behaves as you describe? And you can infer what you will about the fact that I don't think it's worth my time to search for the architecture… :wink:
21 Feb, 2008, Conner wrote in the 15th comment:
Votes: 0
drrck said:
DavidHaley said:
I'd be curious to hear what implementation you're talking about, and how many computers (that people would have access to in this context) run it…


Apparently not curious enough to Google ;)


Perhaps, based on what you'd said so far, he lacked any sufficient search terms to use on Google. Or, perhaps, he was trying to give you a chance to dig yourself out of the hole you've dug yourself into here by so far showing to the majority of the membership that you favor spouting off what others can't bring themselves even try to side with due to its absurdity. :(

Or, maybe he just felt that he'd already adequately presented his case and it wasn't worth wasting his time to try to prove your argument for you because it'd be inappropriate for him to do so. :shrug:
21 Feb, 2008, Tommi wrote in the 16th comment:
Votes: 0
Quote
he was trying to give you a chance to dig yourself out of the hole you've dug yourself into here by so far showing to the majority of the membership that you favor spouting off what others can't bring themselves even try to side with due to its absurdity. :(


Oh perhaps drrck feels left out now the copyright discussion has ended and was after some more attention. :biggrin:
21 Feb, 2008, drrck wrote in the 17th comment:
Votes: 0
…or, more realistically speaking, perhaps I didn't feel the need to turn yet another thread into a long, drawn-out pissing contest simply because certain people are die-hard skeptics and have trolling cheer-leaders to egg them on ;)

</conversation>
21 Feb, 2008, David Haley wrote in the 18th comment:
Votes: 0
Geez, drrck, all I asked you for was a single machine architecture that is used by MUD developers. How is that turning the thread into a "pissing contest"? I'm starting to become a "die-hard skeptic" of your claim because you keep refusing to give specifics…
21 Feb, 2008, Guest wrote in the 19th comment:
Votes: 0
Skepticism is a good thing. This country would be in a lot better shape if a lot more people adopted a healthy skepticism, but that's a discussion and debate for a whole other forum ( or blog even ).

And I don't think it's at all fair to say that anyone here has trolling cheer leaders either. We're all just very opinionated, in case it wasn't clear yet :P

David's question was perfectly valid btw, since I've yet to run into any sort of architecture either where integer rollover results in a zero value. And I'll be up front, I don't feel like spending the time in a long drawn out Google hunt to find out either. Simply answering the question would have saved at least two of us the time, and shared some knowledge with others. Isn't that what we're all here for in the end?
21 Feb, 2008, drrck wrote in the 20th comment:
Votes: 0
Samson said:
And I don't think it's at all fair to say that anyone here has trolling cheer leaders either. We're all just very opinionated, in case it wasn't clear yet :P


Opinionated is fine. Hell, I'm also very opinionated. I classify trollish cheer-leading as posting content that is negative, personal, and completely unrelated to the topic at hand, just to be on the bandwagon. Using that definition, there's been two such perpetrators on this particular thread. I'll leave it as an exercise for the reader to figure out who I'm referring to.

Anyway, I'm seriously done with this conversation unless/until the OP decides to shed some more light on the topic, so take from it what you will.
0.0/50