64-bit warning cleanliness patch

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • AnonymousHero
    Veteran
    • Jun 2007
    • 1393

    64-bit warning cleanliness patch

    I've attached a little patch to cmd4.c to get it to compile cleanly on 64-bit (Ubuntu). The patch is against r1867.
    Attached Files
  • konijn_
    Hellband maintainer
    • Jul 2007
    • 367

    #2
    Originally posted by AnonymousHero
    I've attached a little patch to cmd4.c to get it to compile cleanly on 64-bit (Ubuntu). The patch is against r1867.
    Thank you. It would seem that there has to be a better way than declaring those numbers , no ?

    T.
    * Are you ready for something else ? Hellband 0.8.8 is out! *

    Comment

    • AnonymousHero
      Veteran
      • Jun 2007
      • 1393

      #3
      Yeah, it seems a bit excessive, but I couldn't think of a prettier (and portable) way to do it.

      Comment

      • zaimoni
        Knight
        • Apr 2007
        • 590

        #4
        Originally posted by konijn_
        Thank you. It would seem that there has to be a better way than declaring those numbers , no ?

        T.
        One-line fix for C99 compilers (including GCC on Ubuntu):
        Code:
        -       int page = (int)vpage;
        +        intptr_t page = (intptr_t)vpage);
        Casting void* to intptr_t is always safe in C99. MSVC doesn't have stdint.h as it only implements C90, so the above isn't usable as-is.

        Note that on sufficiently strict hardware, you die on the function call to do_cmd_option_aux anyway. If the hardware both requires special pointer registers to do anything, and faults instantly on an invalid pointer entering those registers: fatality during evaluating the arguments for the function call, if not in constructing the reference data structs to begin with.

        So, if MSVC is to be supported, the given patch is indeed minimal.
        Zaiband: end the "I shouldn't have survived that" experience. V3.0.6 fork on Hg.
        Zaiband 3.0.10 ETA Mar. 7 2011 (Yes, schedule slipped. Latest testing indicates not enough assert() calls to allow release.)
        Z.C++: pre-alpha C/C++ compiler system (usable preprocessor). Also on Hg. Z.C++ 0.0.10 ETA December 31 2011

        Comment

        • Pete Mack
          Prophet
          • Apr 2007
          • 6883

          #5
          A reasonable thing to do is use size_t (or long), and to typedef size_t appropriately for windows on x86 and x64.

          Also, can't you use 4L etc for long integers?

          Comment

          • zaimoni
            Knight
            • Apr 2007
            • 590

            #6
            Originally posted by Pete Mack
            A reasonable thing to do is use size_t (or long), and to typedef size_t appropriately for windows on x86 and x64.
            Code:
            #include <stddef.h>
            (which is already happening, and will typedef size_t even in C90) Unfortunately, it's implementation-defined in C99 whether size_t is the same as uintptr_t.

            Originally posted by Pete Mack
            Also, can't you use 4L etc for long integers?
            Yes. That's probably not what's frying 64-bit *NIX, however.
            Zaiband: end the "I shouldn't have survived that" experience. V3.0.6 fork on Hg.
            Zaiband 3.0.10 ETA Mar. 7 2011 (Yes, schedule slipped. Latest testing indicates not enough assert() calls to allow release.)
            Z.C++: pre-alpha C/C++ compiler system (usable preprocessor). Also on Hg. Z.C++ 0.0.10 ETA December 31 2011

            Comment

            Working...
            😀
            😂
            🥰
            😘
            🤢
            😎
            😞
            😡
            👍
            👎