Vincent Untz wrote:Le mercredi 05 mars 2008, à 08:25 -0800, Rich Burridge a écrit :Bug #520474 - Calculator uses 06 in place of decimal http://bugzilla.gnome.org/show_bug.cgi?id=520474 is a memory corruption problem. See the bug evaluation for more details. This is a major problem with a simple fix. There are no UI or string changes. I request permission to check in this fix for the version of gcalctool that will go into GNOME 2.22.0I'm a bit worried since it might fix things, but it also means there are places where we write in fnum without checking the length. I did a quick grep: display.c: /* Move from scratch pad to fnum, reversing the character order. */ display.c: return(make_fixed(MPnumber, v->fnum, base, MAX_DIGITS, TRUE)); display.c: STRCPY(fixed, make_fixed(MPmant, v->fnum, base, MAX_DIGITS-6, TRUE)); functions.c: STRCPY(v->fnum, v->display); functions.c: ui_set_display(v->fnum, -1); gtk.c: STRNCPY(v->fnum, v->display, MAX_DIGITS - 1); gtk.c: ui_set_display(v->fnum, -1); Shouldn't STRNCPY be used everywhere, instead of STRCPY? (now, maybe the patch you propose is also needed, but it's hard for me to know) Well the offender (the one causing the memory corruption in this case) is the new code in ui_set_display() in gtk.c. At line 974 there is: localize_number(localized, str); str = localized; v->fnum is being passed into ui_set_display(). The string that's coming out of localize_number is larger that it was going in, and it's being reassigned back to v->fnum. By adjusting it's initial size to allow for that (potential) expansion, the problem goes away. The v->display uses aren't a problem because its size is much larger and localize_number() isn't being called. No doubt the code could be improved even more (and hopefully for the next development release that can be done), but this simple change solves the immediate problem. Note that the patch doesn't really need to adjust the size of snum to MAX_LOCALIZED (as well as fnum) as that is currently not used with localize_number(). |