[CF-Devel] Common/loader.[lc] bug, player file corruption ahead

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

David Delbecq wrote:

>
     
      Concerning the third, that is why i tried to prevent use of strlen as much as 
     
     >
     
      possible. Sorry to miss the subtype error, i checked code several time and 
     
     >
     
      was looking at mailing list for strange 'saving behaviour bug' which could 
     
     >
     
      arise before removing old codes from comments. I thought there was no more 
     
     >
     
      problem (hey, the first error i found during beta test is experience badly 
     
     >
     
      saved, could you imagine the mob rushing on me if i had commited it? :) )
     
     >
     
      I understand use of strlen would be easier. If you want to change code and use 
     
     >
     
      back strlen (simply the code FAST macros to change a bit), i won't blame you 
     
     >
     
      neither will i try to change again the code to remove the strlen. But since 
     
     >
     
      the objects structure is something that do not change a lot as time goes on, 
     
     >
     
      i thought having a code a bit more difficult there but faster was a good 
     
     >
     
      tradeoff. the Object_diff is not a function that changes every week, am i 
     
     >
     
      wrong?
     
     
  My philosphy is that in most times, I'd trade some execution time for less 
prone programming errors.

  But more to the point, any decent compiler (and gcc qualifies) will not 
actually make function calls to strlen() for constant string data.

  Obviously, if you do something like:

my_function(char *str)
{
    int x = strlen(str);
...
}

  The compiler has no way of knowing of str is a constant, and thus the strlen 
remains.  However, since the loader.l uses macros, the compiler basicaly can 
turn that into a 'strlen("subtype ")'..., and thus know the appropriate length 
it needs to use.

  This is my real point why strlen should be used - it would be no slower than 
existing code (for systems with decent compilers), but easier to maintain and 
less prone to bugs.



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