View Issue Details

IDProjectCategoryView StatusLast Update
0000556LDMud 3.3Portabilitypublic2008-07-14 18:57
Reporterzesstra Assigned To 
PrioritylowSeverityminorReproducibilityN/A
Status newResolutionopen 
Platformx86_64OSMacOS XOS Version10.5.x
Summary0000556: Change code which assumes that p_int and mp_int are always a long.
DescriptionCurrently 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'?
TagsNo tags attached.

Relationships

related to 0000554 resolvedzesstra LDMud 3.3 port.h should use stdint.h, inttypes.h and stdbool.h if available 
related to 0000528 resolvedzesstra LDMud 3.3 sprintf() fails to print int values larger than 2^32 - 1 correctly 
parent of 0000565 resolvedzesstra LDMud 3.5 Hash in store_prog_string() assumes 32 bit pointers 

Activities

2008-07-14 16:14

 

p_int-type-warnings.log (40,684 bytes)

zesstra

2008-07-14 18:53

administrator   ~0000728

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.

2008-07-14 18:57

 

Issue History

Date Modified Username Field Change
2008-07-14 16:13 zesstra New Issue
2008-07-14 16:14 zesstra File Added: p_int-type-warnings.log
2008-07-14 16:15 zesstra Projection none => major rework
2008-07-14 16:15 zesstra ETA none => > 1 month
2008-07-14 16:16 zesstra Relationship added related to 0000554
2008-07-14 16:17 zesstra Relationship added related to 0000528
2008-07-14 18:53 zesstra Note Added: 0000728
2008-07-14 18: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 18:57 zesstra File Added: mp_int-type-warning.log
2008-09-09 09:27 zesstra Relationship added parent of 0000565