[CF-Devel] bug in some libc 64 bit parsing

crossfire-devel-admin at archives.real-time.com crossfire-devel-admin at archives.real-time.com
Tue Mar 18 17:28:16 CST 2003


Hello,


Yes this release of Linux Mandrake (Redhat derived) 6.0 is quite old, and had
some other problems : so it's possible that there are few people that already
have it at this time.

But this is perhaps not the only OS that have this problem : it's perhaps this
release of glibc (2.1.1) on x86 ?? (does anyone have this release ?)


I was the first surprised with this bug, and for my own, on this computer, I
will perhaps change atoll at system wide .h files.


I understand very well your problem : and it's perhaps better to see if someone
else have the same problem. If someone ask why he have the message "Experience
for level 112 is lower than previous level (1988232704 <= 3141600000)" at server
start, it's that problem.


Olivier.



En réponse à Mark Wedel <
     
     mwedel at sonic.net
     
     >:

>
     
     
      huet.o at free.fr
      
       wrote:
     
     >
     
      > Hello,
     
     >
     
      > 
     
     >
     
      > I took the last cvs snapshot of Crossfire Server, and I had a problem
     
     >
     
      when I
     
     >
     
      > launch the compiled server : the "experience" table don't load at the
     
     >
     
      first
     
     >
     
      > "big" (real 64 bit) level value (12 I think).
     
     >
     
      > 
     
     >
     
      > After some tracing, I noticed it's because my "atoll" libc function is
     
     >
     
      broken
     
     >
     
      > (the one with GLIBC_2.1.1 of a Mandrake/Redhat 6.0 Linux Distribution
     
     >
     
      on x86).
     
     >
     
      > 
     
     >
     
      > atoll in this version of the libc+distribution act on 32 bit values
     
     >
     
      only : see
     
     >
     
      > example of this program :
     
     >
     
      >
     
     >
     
     
     >
     
        I'd note that redhat 6.0 is pretty darn old.
     
     >
     
     
     >
     
        I'm a bit mixed on this.  On the one hand, I'd like for crossfire to
     
     >
     
      work on 
     
     >
     
      as many systems as reasonably possible (however if that was really the
     
     >
     
      case, 
     
     >
     
      then I shouldn't use long long).  OTOH, I really don't want to include
     
     >
     
      functions 
     
     >
     
      for every call that may not work quite right on every system.
     
     >
     
     
     >
     
        This is more of a problem - this isn't an issue of missing a function
     
     >
     
      (in 
     
     >
     
      which case something like a #ifndef HAVE_ATOLL myatoll() ... #endif) -
     
     >
     
      something 
     
     >
     
      like a myatoll would be needed.
     
     >
     
     
     >
     
        this poses problems in that a developer could use the wrong call
     
     >
     
      someplace, 
     
     >
     
      getting the wrong behaviour.  It also means that if the OS in question
     
     >
     
      has a 
     
     >
     
      more optimized version, that won't get used.
     
     >
     
     
     >
     
     
     >
     
     
     >
     
     
     >
     
      _______________________________________________
     
     >
     
      crossfire-devel mailing list
     
     >
     
     
      crossfire-devel at lists.real-time.com
      
      
     >
     
     
      https://mailman.real-time.com/mailman/listinfo/crossfire-devel
      
      
     >
     
     
     
_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel
     
     
    


More information about the crossfire mailing list