[CF-Devel] Some warning cleaning

[crossfire-devel at archives.real-time.com]

Nicolas Weeger wrote:
>
     
      Hello.
     
     >
     
     
     >
     
      I committed a few patches to clean some compilation warnings (mainly 
     
     >
     
      type matching, for map coordinates & stats).
     
     >
     
      There are some left, because stuff like 'sint16 + sint16' yields (at 
     
     >
     
      least under Windows) an int, thus integral size mismatch in function 
     
     >
     
      call if it expects a sint16 (case of most map coordinates-related 
     
     >
     
      functions). But fixing those ones would require explicit casts around 
     
     >
     
      all (sint16+sint16), which sounds pretty ugly...
     
     
  Yep.

>
     
     
     >
     
      Most of the other warnings I have left are signed/unsigned mismatch. I'd 
     
     >
     
      want to fix'em, but this is potentially easy to break things with those 
     
     >
     
      fixes.
     
     >
     
      What do you think? Is it worth trying to fix signed/unsigned mismatches, 
     
     >
     
      or do we just let'em, hoping they won't be a bother later?
     
     
  Well, I don't think most of these warnings were that big an issue.

  The biggest issue with changing signed/unsigned might be any variables.  For 
example, you could have something like:

  unsigned u;
  signed s;

  ... where s is set to some positive value ...

  u = s;

  ... other code where s may now be assigned negative values ..

  So if s was changed to unsigned, that could break some code.

  Which means to fix those up, the code has to be properly examined to see if 
there are any side effects.

  I don't really think it is worth putting a bunch of casts into the code - it 
seems to be that doesn't really 'fix' anything, and rather just masks a warning, 
which seems pretty pointless.  Also, it is likely to cause problems if any of 
the variables in question change in their type, as now the casts are potentially 
improperly changing the type of value.


>
     
     
     >
     
     
     >
     
      Also, in common/porting.c, is there a compelling reason why 
     
     >
     
      strdup_local(), strncasecmp(), strcasecmp() and strcasestr_local() take 
     
     >
     
      char* and not const char* as arguments? Since strings are used only for 
     
     >
     
      comparison, and not changed.
     
     
  no compelling reason.  When was the 'const' keyword added to the C spec?  Very 
possible that code predates that code.



_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel