#200 Check return codes everywhere

open-fixed
None
5
2007-05-15
2007-03-16
No

Some checks for return codes are missing.

Examples:
Would you like to add more error handling for return values from "malloc" like in the function "newASCIIString" and from "printf" in the function "sendCompiledNodeToReWire"?
http://freewrl.cvs.sourceforge.net/freewrl/freewrl/freewrl/CFuncs/EAI_C_CommonFunctions.c?revision=1.4&view=markup
http://freewrl.cvs.sourceforge.net/freewrl/freewrl/freewrl/CFuncs/Component_Networking.c?revision=1.26&view=markup

Discussion

  • John Stewart

    John Stewart - 2007-03-18
    • assigned_to: nobody --> crc_canada
     
  • John Stewart

    John Stewart - 2007-03-20

    Logged In: YES
    user_id=58616
    Originator: NO

    Thanks for the reminder - sometimes when coding quickly, it is easy to skip past such things.

     
  • Markus Elfring

    Markus Elfring - 2007-03-20

    Logged In: YES
    user_id=572001
    Originator: YES

    Would you like to detect every error situation as early as possible?

     
  • John Stewart

    John Stewart - 2007-03-21

    Logged In: YES
    user_id=58616
    Originator: NO

    ok, so far all mallocs, frees, and reallocs are checked. if a problem is encountered, freewrl stops, and a file/line number is printed. We are actually putting in new code to destroy the scene graph, as part of a memory management update, that will allow better algorithms to keep track of malloc'd/free'd memory.

    The code will be in CVS shortly, and will be in the next development release of FreeWRL.

     
  • Markus Elfring

    Markus Elfring - 2007-03-21

    Logged In: YES
    user_id=572001
    Originator: YES

    Are you going to complete the checking for returned error codes?
    - fprintf
    - fclose

     
  • John Stewart

    John Stewart - 2007-03-23

    Logged In: YES
    user_id=58616
    Originator: NO

    Hi Elfring;

    Hmmm - you willing to help?

    As code gets revisited, the error checking gets tightened. The EAI/SAI code in FreeWRL is getting a revisit right now, though. Expect it to be getting better. Yes, sometimes in my lab I'm getting crashes when working on the MidiControl tests. There is a problem of what action to take when an error is encountered. Stop? wait and try again??

    That still leaves a bunch of sscanfs, and, possibly other assorted calls in the code.

    Thanks - John Stewart.

     
  • John Stewart

    John Stewart - 2007-05-15

    Logged In: YES
    user_id=58616
    Originator: NO

    All code that is getting refactored is getting better error management. MALLOC/FREE_IF_NZ macros defined that allow us to track memory usage. Recently, the Javascript interface has had a lot of attention; code that has been refactored has type checking now.

    Thanks for reminding us to do this...

    John Stewart.

     
  • John Stewart

    John Stewart - 2007-05-15
    • status: open --> closed-fixed
     
  • Markus Elfring

    Markus Elfring - 2007-05-15
    • status: closed-fixed --> open-fixed
     
  • Markus Elfring

    Markus Elfring - 2007-05-15

    Logged In: YES
    user_id=572001
    Originator: YES

    Can the tool "http://splint.org/" help to find any remaining issues?

     
  • John Stewart

    John Stewart - 2007-05-24

    Logged In: YES
    user_id=58616
    Originator: NO

    I had a look at splint. Tried to run it, but did not succeed. I actually use "valgrind" to runtime error check, and, most memory references are potentially checked by macros, and, if enabled, malloc/frees are tracked.

    What is really helping is pressing vrml/x3d mistakes through FreeWRL. This tends to help show runtime errors, eg, not enough parameters, etc. Unfortunately, not everything will be caught.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks