[CF-Devel] Alchemy exploit

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

Andreas Kirschbaum wrote:
>
     
     
     >>
     
     3) use of any 'long' or 'unsigned long' variables is discouraged, as past
     
     >>
     
     experience has shown that there is no guarantee if these will be 64 or 32
     
     >>
     
     bit values.  Instead use the uint32 or uint64 types, depending on what you
     
     >>
     
     need (maybe this has been clarified in more recent versions of the C
     
     >>
     
     standard).  But in any case, use of the uint/sint types is still preferred -
     
     >>
     
     I note that object.h defines nrof as a uint32.
     
     >
     
     
     >
     
     
     >
     
      I changed the variables to uint32 type. But now I need a type cast in
     
     >
     
      the call to LOG(): LOG(..., "...%lu...", (unsigned long)value_item, ...)
     
     >
     
      because "%lu" wants an unsigned long.
     
     
  That's sort of an odd approach to take.  I'd think the easier fix is to just 
use the right format (%d) instead of doing casts.

>
     
     
     >
     
     
     >
     
      Unfortunately, I found another problem with my patch: after doing
     
     >
     
      alchemy, the resulting item is not identified and (always?) cursed.
     
     >
     
      Therefore query_cost() returns a value much less than a player would
     
     >
     
      actually get for that item.
     
     >
     
     
     >
     
      So I need a means to pretend the item to be identified and not be cursed
     
     >
     
      to calculate the price for it. I could imagine two alternatives for
     
     >
     
      doing that:
     
     >
     
     
     >
     
      a) temporarily change the item flags, call query_cost() and restore the
     
     >
     
         flags.
     
     >
     
     
     >
     
      b) add a new flag F_SELL_IDENTIFIED to query_cost() and modify the price
     
     >
     
         calculations accordingly.
     
     >
     
     
     >
     
      My preference would be second alternative because temporarily modifying
     
     >
     
      objects does not make the code easier to understand.
     
     
  Actually, something like an F_IDENTIFIED that is another flag that can be 
orred with the other ones makes more sense, like the F_NO_BARGAIN is.

  Thus you could do something like query_cost(..., F_BUY | F_IDENTIFIED) or the 
like, so that two different parameters don't need to be defined for the behaviour.

  However, I do recall that other places in the code do play around with the 
FLAG_IDENTIFIED value - perhaps a little confusing, but presuming it is 
adequately commented, not so much so.


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