Results 1 to 7 of 7

Thread: A habit of ignoring warnings is a bad habit

  1. #1

    Unhappy A habit of ignoring warnings is a bad habit

    I don't know when, but I grew used to ignoring compiler warnings (maybe because the compiler often whines about silly things like nested comments or descendants hiding ancestor methods where I fully intend it to be that way).
    So instead of checking them from time to time I let them accumulate for years.
    Today I have finally browsed through that pile of a 100+ warnings.

    [whimper]

    There were horrible bugs in mission-critical error handling code designed for stability. Only remaining uncaught because I never paid attention to a dozen or so of "Local variable "X" does not seem to be initialized".

    It led to the code I thought was rock solid iterating over trash pointers.

    And here I was wondering why my engine was sometimes crashing without reporting exceptions properly or simply Logging "exception caught, details later" with said details never logged. Or crashing with weird cascading errors on exit.

    Now I know why.
    Never, ever develop a habit of ignoring warnings!

  2. #2
    compiler warnings could be pointing out the first step of a bug indeed.
    This is my game project - Top Down City:
    http://www.pascalgamedevelopment.com...y-Topic-Reboot

    My OpenAL audio wrapper with Intelligent Source Manager to use unlimited:
    http://www.pascalgamedevelopment.com...source+manager

  3. #3
    PGDCE Developer de_jean_7777's Avatar
    Join Date
    Nov 2006
    Location
    Bosnia and Herzegovina (Herzegovina)
    Posts
    287
    Quote Originally Posted by Chebmaster View Post
    Never, ever develop a habit of ignoring warnings!
    I usually try to fix and understand all warnings, and silence those which are intentional so I get a clean output. At least in lazarus I hide the "unused parameter" for generic callbacks with {%H-}. But if I do expect to use them eventually then I don't hide them. Helped a lot with my engine. Also I try to have heaptrc and valgrind show no leaked memory or problems. Valgrind is very helpful to further find memory corruption or invalid use. Doing it regularly helps decrease the chance a memory corruption will lead to endless hours of debugging
    Existence is pain

  4. #4
    First time I hacked Allegro I read the internal documentation and it said that they'll never accept code that compiler shows any warning from. Since then I realized that was a good programming habit. Unfortunately they seem to drop that demand.

    Anyway I've found it is good to pay attention to warnings and hints as they help a lot to prevent hidden (and not so hidden) bugs and problems.
    No signature provided yet.

  5. #5
    Lesson #next: The "Conversion between ordinals and pointers is not portable" is serious, it really means "You have bungled your type-casts, your pointer arithmetics is performed in 32-bits and WILL crash on 64-bit platforms"

    Most often than not is a stray longint somewhere in the mix... Combined with the compiler's rule of choosing the lowest integer size to perform calculations, a disaster.

    For example,
    Code:
    function TChepersyMemoryManagerChunk.Alloc: pointer;
    var 
      i, k: integer;
    [...]
      Exit(pointer(ptruint(Self) + ptruint(k) * f_Size));
    Is a flop. Why? f_Size is a longint so the casts ptruint(k) and ptruint(Self) are useless, these are brought down to dword and everything goes to hell.

    The proper solution is
    Code:
      Exit(pointer(ptruint(Self) + ptruint(k * f_Size)));
    Lo, the warning had disappeared.

    I wish the fpc dev team had chosen more informative words: I was under false impression "not portable" was referring to platforms with no pointer arithmetics.

  6. #6
    Allegro has that "Conversion between ordinals and pointers" in few places, and I fixed it by creating an "union" (you know, a "CASE inside RECORD"). Of course it should be sure that integer and pointer are the same size.

    IMHO it is a bad practice, even in C and Assembler.
    No signature provided yet.

  7. #7
    Ignore everything I said above, the reason is the compiler EXTENDS calculations to 64 bits, then gets nervous as it rounds a 64-bit signed integer down to a 32-bit pointer.
    These warnings don't show at all when the same code is compiled for x86-64.

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •