View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000634 | LDMud 3.3 | Portability | public | 2009-05-05 13:49 | 2009-05-10 10:55 |
Reporter | zesstra | Assigned To | zesstra | ||
Priority | high | Severity | major | Reproducibility | N/A |
Status | resolved | Resolution | fixed | ||
Platform | x86_64 | OS | MacOS X | OS Version | 10.5.x |
Product Version | 3.3.718 | ||||
Target Version | 3.3.719 | Fixed in Version | 3.3.719 | ||
Summary | 0000634: Overflow of number_buffer in object.c | ||||
Description | save_svalue() in object.c uses the static buffer number_buffer to store a textual representation of numbers. sprintf() is used to write into the buffer. Its size is 36, which should be sufficient for even 64 bit integers and our floats. But Gnomi noticed, that the buffer size was not sufficient in one case, where the exponent of a float was printed as 32 bit integer (0xffffffff). 1) This should IMHO not happen. 2) The buffer should only be written with a sprintfn(...,sizeof(number_buffer),...) to prevent such overflows. | ||||
Tags | No tags attached. | ||||
|
Fixed in r2579 by writing the exponent as a uint16_t. I could not reproduce the issue, but Gnomi found out, that on his system (glibc-...) PRIx16 was defined to be %x, although int16_t is a short on that system. This is plain wrong according to the manpage of sprintf. Despite this, SCNx16 is %hx. Additionally all sprintf(), which write into number_buffer were replaced by snprintf(). |
Date Modified | Username | Field | Change |
---|---|---|---|
2009-05-05 13:49 | zesstra | New Issue | |
2009-05-05 13:49 | zesstra | Status | new => assigned |
2009-05-05 13:49 | zesstra | Assigned To | => zesstra |
2009-05-05 13:49 | zesstra | Project | LDMud => LDMud 3.3 |
2009-05-10 10:55 | zesstra | Note Added: 0001093 | |
2009-05-10 10:55 | zesstra | Status | assigned => resolved |
2009-05-10 10:55 | zesstra | Fixed in Version | => 3.3.719 |
2009-05-10 10:55 | zesstra | Resolution | open => fixed |