View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000757 | LDMud 3.5 | Compilation, Installation | public | 2010-08-28 10:33 | 2018-01-30 03:59 |
| Reporter | garamon | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Summary | 0000757: Compiler Warnings on MacOS | ||||
| Description | When compiling the current trunk (svn://svn.bearnip.com/ldmud/trunk@2929) on MacOS 10.6.4 with the standard XCode package, the following (types of) warnings are displayed: # complains about char * being used, maybe because add_message is declared using "const" comm.c: In function ‘flush_all_player_mess’: comm.c:2137: warning: format not a string literal and no format arguments (same in line 3339, 3353, 3708, 4580, 6667, 7030, 7037, 7126, 7134, interpret.c:6932) comm.c:4636: warning: ‘reply_nil’ defined but not used parser.c: At top level: prolang.y:1969: warning: ‘upd_uint32’ defined but not used prolang.y:1977: warning: ‘read_uint32’ defined but not used In file included from parser.c:21: lang.y:7121: warning: format ‘%ld’ expects type ‘long int’, but argument 2 has type ‘bc_offset_t’ # %lld should be fine here, if "long long int" is not system dependent lex.c:862: warning: format ‘%ld’ expects type ‘long int’, but argument 5 has type ‘long long int’ lex.c:864: warning: format ‘%ld’ expects type ‘long int’, but argument 5 has type ‘long long int’ The build completes fine, and the driver works ;-) | ||||
| Tags | No tags attached. | ||||
|
|
The ones in lex.c are actually (in my opinion) a nuisance in MacOS. They define PRIdPTR as "ld" but INTPTR_MAX as 9223372036854775807LL on LP64 architectures. upd_uint32 and read_uint32 are there just in case somebody needs them. I could have I look if I find a portable pragma or at least one for gcc. I think, reply_nil() in comm.c should be removed, I don't remember for what it was used. The warnings about add_message() ist because the callers call it with 'message_flush' which is NULL. add_message() uses this a special case and flushes the buffer. Usually, of course that should be a format string. Its a bit ugly, but has to stay until we re-design add_message() & Co... bc_offset_t is actually a int32_t. The cleanest way would be to create a define PRIdBC_OFFSET as PRId32. |
|
|
I think, some of this was fixed in the meantime. If needed, we should start again with a current list of warnings. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-08-28 10:33 | garamon | New Issue | |
| 2010-11-17 21:12 | zesstra | Note Added: 0001916 | |
| 2010-11-17 21:12 | zesstra | Status | new => acknowledged |
| 2010-11-17 21:26 | zesstra | Source_changeset_attached | => ldmud.git master 076c0b9c |
| 2018-01-29 18:59 | zesstra | Source_changeset_attached | => ldmud.git master 076c0b9c |
| 2018-01-29 21:57 | zesstra | Source_changeset_attached | => ldmud.git master 076c0b9c |
| 2018-01-29 22:16 | zesstra | Status | acknowledged => closed |
| 2018-01-29 22:16 | zesstra | Resolution | open => no change required |
| 2018-01-29 22:16 | zesstra | Note Added: 0002396 | |
| 2018-01-30 03:59 | zesstra | Source_changeset_attached | => ldmud.git master 076c0b9c |
