Code:
// redraw the bottom row totals
for(ii = 0; ii < 11; ii++)
{
XExposeEvent xev;
Dimension ww, hh;
char temp[(sizeof(short unsigned int) +1)];
sprintf(temp, "%u", bottomTotals[ii]);
st0 = XmStringCreateLocalized((char *) temp); // st0 is global
XtVaSetValues(bottom_row_labels[ii], XmNlabelString, st0, NULL);
XmStringFree(st0); // st0 is global
xev.window = XtWindow(bottom_row_labels[ii]);
xev.type = Expose;
xev.display = XtDisplay(bottom_row_labels[ii]);
XtVaGetValues(bottom_row_labels[ii], XmNwidth, &ww, XmNheight, &hh, NULL);
The stack-allocated buffer temp will be overrun as soon as bottomTotals[ii] exceeds 99. If locals are allocated on the stack in program order, which would be typical but cannot be relied on, this will write over the space assigned to ww and hh. Later in the program, ww and hh are written by the call to XtVaGetValues(), and temp is never used again, so the program may run without any indication of a problem. However, since it is undefined behavior™, a C99 compiler can choose to do just about anything with your code: mail it to the North Korean embassy, launch it from Baikonur cosmodrome, etc. You're lucky if you get a bus error; it can simply depend on the total never exceeding 99 and terminate prematurely.
In C, you are expected to
know how much space a string can take. Very importantly, it has
nothing to do with the argument type. A trivial analysis of the problem reveals that the highest total is bottomTotals[10] which should always equal 100000. So the space needed for the temp buffer is 7: six digits and \n. This can be used for all uses of sprintf() and could be made static and declared at toplevel (file scope). It
does not depend on the ABI—32 or 64 bits—at all.
Should have stuck to FORTRAN: there's no way to mess this stuff up.
A few other bugs: you don't shuffle the shoe prior to the first deal. In fact the discards vector is pointless; with a truly random shuffle, you could simply reset the shoe to its initial value, or the previously shuffled value.
(past: 
)
