View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000556 | LDMud 3.3 | Portability | public | 2008-07-14 14:13 | 2008-07-14 16:57 |
| Reporter | zesstra | Assigned To | |||
| Priority | low | Severity | minor | Reproducibility | N/A |
| Status | new | Resolution | open | ||
| Platform | x86_64 | OS | MacOS X | OS Version | 10.5.x |
| Summary | 0000556: Change code which assumes that p_int and mp_int are always a long. | ||||
| Description | Currently the driver contains a lot of code like sprintf("%ld",p_int) which assumes, that p_int is always a long. This surfaced in testing the proposed changes from 0000554. On some systems intptr_t is typdef'ed to an int instead of long (glibc on ILP32 platforms). According to gcc warnings there are 425 of such issues in the driver code (see attached log). For the sake of portability, printf() should only be used directly with hard-coded format specifiers if the type of its argument is guarenteed (e.g. %ld and long), but not if the type is typedef'ed/aliased to in a system-dependent manner (e.g. p_int). Right now it seems not to be an immediate problem, as on most platforms in use for the driver a long apparantly has the needed length for p_int, therefore setting this to a low priority. (On systems with sizeof(int)==sizeof(char*) && sizeof(long) > sizeof(int) the driver will crash in its current state.) The problem can be solved by using a #define from port.h as format specifier (like the ones from inttypes.h, e.g. PRIdPTR) for our own typedef'ed types, e.g. PRI_PINT_PREFIX. Do you have any opinions about how we should handle this? It seems pretty much obvious, that we can't easily change this immediately but it will take time. Or should we ignore it pretty much because working on this has a bad 'return of investment'? | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| related to | 0000554 | resolved | zesstra | LDMud 3.3 | port.h should use stdint.h, inttypes.h and stdbool.h if available |
| related to | 0000528 | resolved | zesstra | LDMud 3.3 | sprintf() fails to print int values larger than 2^32 - 1 correctly |
| parent of | 0000565 | resolved | zesstra | LDMud 3.5 | Hash in store_prog_string() assumes 32 bit pointers |
|
|
Additionally there cases like these: efuns.c:8038: warning: format '%6ld' expects type 'long int', but argument 3 has type 'mp_int' Here the driver expects that mp_int is always a long. In the given case above mp_int is of type long long, because I experimentally used intmax_t for mp_int. Right now, this is mostly prevented in port.h by specifically using the same type as p_int (which is nearly always long, see description). Unfortunately this prevents us from using the intmax_t for mp_int which is nowadays available on most systems. The first priority should be on fixing these hard-coded specifiers for mp_ints, so that we may use long longs (e.g. for the statistics counters). A log of compiler warnings (60) will be attached. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2008-07-14 14:13 | zesstra | New Issue | |
| 2008-07-14 14:14 | zesstra | File Added: p_int-type-warnings.log | |
| 2008-07-14 14:15 | zesstra | Projection | none => major rework |
| 2008-07-14 14:15 | zesstra | ETA | none => > 1 month |
| 2008-07-14 14:16 | zesstra | Relationship added | related to 0000554 |
| 2008-07-14 14:17 | zesstra | Relationship added | related to 0000528 |
| 2008-07-14 16:53 | zesstra | Note Added: 0000728 | |
| 2008-07-14 16:53 | zesstra | Summary | Change code which assumes that p_int is always a long. => Change code which assumes that p_int and mp_int are always a long. |
| 2008-07-14 16:57 | zesstra | File Added: mp_int-type-warning.log | |
| 2008-09-09 07:27 | zesstra | Relationship added | parent of 0000565 |
