• Anon (unregistered)

    Will that even compile? Not on my compiler it wont!

    In C++ free is templated, but it still expects a pointer as input... int n = 4; free(n); error C2664: 'free' : cannot convert parameter 1 from 'int' to 'void *'

    This compiles though, but I expect it will crash: int n = 4; free(&n);

  • rotu (unregistered) in reply to python, php, perl, mono, .net
    python:
    Blah. This is why no one uses C any more.

    really now?

  • David Cameron (unregistered) in reply to MrHen
    MrHen:
    Not that this is incredibly minor compared to the rest of it, but I like that it returns 1 when it errors out. Very intuitive.

    That is normal. The semi formal standard for C is to return 0 if there were no errors and an error number if there were errors.

  • (cs)

    This is why javac and compilers for many other languages die with a nice "error: unreachable code". I take it C compilers aren't that smart, or simply don't care? Does GCJ throw an error for unreachable code? (for Java I mean)

  • Peter Y (unregistered)
      return 0;
    
      /* Free up the memory used in the function. */
      free( peer );
      free( parent );
      free( children );
      free( n );
    

    It should be pretty clear that all the free's are non-reachable code. Why aren't these lines removed? Not sure if deleting nodes during a traverse is going to cause a few minor problems perhaps? Nothing like manipulating a data structure without knowing what you are doing.

    Captcha: onomatopoeia ... just for the sake of slowing down my typing. Or is it the sound of two hands typing.

  • anonymous (unregistered) in reply to snoofle

    I think I understand why you hated, I mean it is much better to use ++x

  • anonymous (unregistered) in reply to Samah
    Samah:
    This is why javac and compilers for many other languages die with a nice "error: unreachable code". I take it C compilers aren't that smart, or simply don't care? Does GCJ throw an error for unreachable code? (for Java I mean)

    C programmers do not want compiler telling them what is right what is not. We usually have long memorized all of ANSI/ISO Standard becuase we can and also because we think that is a fundamental requirement that you know what you are doing. C is quite small compared to your Java/C++ and such Garbage (Collected) languages, and having the whole Standard in ones head is actually a good thing.

  • Rhialto (unregistered) in reply to newt0311
    newt0311:
    in C, there is no way to differentiate between ints and pointers.

    Do you know any C at all? I must say that the replies in today's submission show almost more incompetence than the submission itself! (More so than usually, anyway). Maybe I notice because it is written in a language I understand this time.

    No, free(n) would not even compile.

  • Tim (unregistered) in reply to Rhialto
    Rhialto:
    newt0311:
    in C, there is no way to differentiate between ints and pointers.

    Do you know any C at all? I must say that the replies in today's submission show almost more incompetence than the submission itself! (More so than usually, anyway). Maybe I notice because it is written in a language I understand this time.

    No, free(n) would not even compile.

    And with that final comment, you point out that it's only the compiler that takes offense at such a line. As far as any compiled code is concerned, an int is just data and so is a pointer (though possibly of different lengths and with different alignment requirements, dependent on the architecture.)

  • (cs) in reply to Rhialto
    Rhialto:
    No, free(n) would not even compile.
    daid@slayer:~/test$ cat main.c #include <stdio.h> #include <stdlib.h>

    int main(int argc, char** argv) { int n=0; free(n); return 0; } daid@slayer:~/test$ gcc -Wall -o main main.c main.c: In function main': main.c:7: warning: passing arg 1 offree' makes pointer from integer without a cast daid@slayer:~/test$ gcc -v Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux Thread model: posix gcc version 3.3.5 (Debian 1:3.3.5-8ubuntu2.1) daid@slayer:~/test$

    gcc 3.3.5 says otherwise. (and it runs without crashing :P)

  • Tragomaskhalos (unregistered)

    Not sure which is the biggest WTF here, the original code or some of the comments people have posted - I suppose it's a sign of the times that the kids today just don't know their C. Not that it was neccessarily any better in the good old days - I remember once pointing out to a colleague where he needed to stick a free() into his code to prevent a memory leak, and his response was basically "huh? I didn't know you had to do that". I think he ended up moving into sales.

  • joerbanno (unregistered) in reply to slinkp
    slinkp:
    You guys keep talking about the compiler barfing... I don't even use C so I had no good excuse for not actually trying it :-)

    #include <stdlib.h>

    typedef char Node;

    void traverseGroup( Node *peer, Node *parent, Node *children[], int n ) { free( peer ); free( parent ); free( children ); free( n ); }

    int main() { Node *peer = "milton"; Node *parent = "bob"; Node *children[2] = {"michael bolton", "samir"}; int n = 2;

    traverseGroup(peer, parent, children, n);
    return 0;
    

    }

    pw@sweetums $ gcc wtf.c wtf.c: In function 'traverseGroup': wtf.c:11: warning: passing argument 1 of 'free' makes pointer from integer without a cast

    pw@sweetums $ ./a.out Segmentation fault

    But hey, that's easily fixed, we can get rid of that annoying warning by changing just one line:

      free( (char *)n );
    

    There, problem solved!

    pw@sweetums C $ rm -f a.out pw@sweetums C $ gcc -Werror wtf.c pw@sweetums C $ ./a.out Segmentation fault

    In fact, we never get as far as free(n), it segfaults on the call to free(peer).

    It makes perfect sense Node *peer = "milton"; is not allocated on the heap so doing a free(peer) is indeed a big WTF

  • BA (unregistered) in reply to Samah
    Samah:
    This is why javac and compilers for many other languages die with a nice "error: unreachable code". I take it C compilers aren't that smart, or simply don't care? Does GCJ throw an error for unreachable code? (for Java I mean)

    C compilers are smart, smart enough to know that unreachable code is an error on the part of the programmer and won't affect the program. Dying for semantics is useless, does JavaC die for this:

    if (x = y) { /* Always execute */ }

    Syntactically valid, semantically wrong, and actually more of a problem than dead code.

    Plus (or minus, depending on your view of things), unreachable code may not always have to be unreachable in C. You can always go muck about with the instruction pointer if you really feel it is necessary.

    The beauty of C is not its safety or ease of use, but its ability to do really complex stuff with no interference.

  • Donald Knuth (unregistered) in reply to snoofle
    snoofle:
    A long time ago, I worked with this guy who thought it was cute to do something like this:
    
    /********************************************
     * very long comment                        *
     * blah blah blah */ x++; /* blah blah blah *
     * very long comment                        *
     ********************************************/
    

    Man, I hated that guy.

    This looks like an attempt at Literate Programming.

  • b0x0rz (unregistered) in reply to snoofle

    i hate him too.

  • Homer (unregistered)

    What kind a jackass tries to free an int? At least the code is dead but that still deserves a swift whack in the nuts with a baseball bat.

  • Anonymous Coward (unregistered) in reply to Rhialto
    Rhialto:
    newt0311:
    in C, there is no way to differentiate between ints and pointers.

    Do you know any C at all? I must say that the replies in today's submission show almost more incompetence than the submission itself! (More so than usually, anyway). Maybe I notice because it is written in a language I understand this time.

    No, free(n) would not even compile.

    Actually, it does - if you are using a C compiler, not feeding C into a C++ compiler. Perhaps you should spend more time checking your facts and less time disparaging others.

  • JCW (unregistered) in reply to BA
    BA:
    if (x = y) { /* Always execute */ }

    Actually: if (x = y) { /* Execute unless y == 0 */ }

  • The WonderBlogger (DAL) (unregistered)

    Perhaps all the calls to Free() are meant as political statements, not programming statements...it's more a vague yearning, not a requirement, which explains why he places the call to free after the return statement.

  • Blaufish (unregistered) in reply to snoofle
    snoofle:
    A long time ago, I worked with this guy who thought it was cute to do something like this: ...code... Man, I hated that guy.

    I love it! Excellent practice in writing intentionally unmaintainable code. Did he have anything explicitly against his fellow developers, or did he hate all mankind? ;)

    Perhaps it would be even more evil to do:

    /***********************************************
     * very long comment                           *
     * blah blah blah */ return; /* blah blah blah *
     * very long comment                           *
     ***********************************************/
    important code;
    important code;
    

    That bug may remain hidden for a long long time...

  • John Doe (unregistered) in reply to Alistair

    "n = n;" IS NOT NECESSARILY DEAD code in C++...

    In fact if those are arrays and "operator=" doesn't compare its argument to this, very bad things could happen.

  • Asif Youcare (unregistered) in reply to Thomas
    Thomas:
    Why would this guy pass as an argument the parent and the children of the node? Shouldn`t the data structure be organized in the way that you can actually track the node`s parent and his children having the node. Bad data structuring too.

    Agree 100%. Just looking at the declaration of the function forewarns me it will be a WTF. Hadn't the guy heard of structs and handles?

    Every first year CS student has to program tree creation, traversal, and destruction. This guy must have been sick that week.

  • (cs)

    But there are meaningful comments in the function ;-)

    I think that Mr. Memory Leak will also find ways to write stupid Code in C#.NET and outwit the GC...

    This guy will forget to implement IDisposable to free unmanged resources...

  • Todd (unregistered) in reply to PJH

    How about free(willie);

    Sadly, he'd still be in his pool in Oregon as the code never gets executed. :(

  • BtM (unregistered) in reply to PseudoNoise
    PseudoNoise:
    Oy! OK, I'm not going to point fingers, but some people have forgotten their C pointers.

    Node aNode; Node nodeArray[] = { /* whatever */ };

    &aNode is a Node* nodeArray is a Node* &nodeArray is a Node**

    Not quite -- in traditional (K&R) C, it's a Node*, and in ISO Standard C, it's a Node (*)[N] (pointer to N-element array of Node), where N is the number of elements in the initializer.

    &nodeArray[0] == nodeArray, and they're both Node*
  • hamstray (unregistered) in reply to Samah
    Samah:
    This is why javac and compilers for many other languages die with a nice "error: unreachable code". I take it C compilers aren't that smart, or simply don't care? Does GCJ throw an error for unreachable code? (for Java I mean)

    The "unreachable code" error is quite annoying. Imagine you need a quick way to stub some function in someone else's code for debugging purposes and it's riddled full of those /* */ style comments...

  • S (unregistered) in reply to SomeCoder
    SomeCoder:
    mpd:
    A cardinal rule of C coding is never free memory you (the function) don't allocate. (Yeah, free'ing the integer will also cause problems.)

    Yeah, tell that to Microsoft in their MFC libraries frustrated sigh

    Or the people that came up with Symbian and Nokia for crapping up S60. You want to set the title of the window in Avkon? Ok, let's not use descriptors, since they would be evil. The called function would have to make a copy of the data it's given. That's not nice. Let's rather make it this way:

    • the application allocates a dynamic buffer
    • the application copies the title to that buffer
    • the application gives the buffer to CAknTitlePane

    No deleting, nothing. If you do, the app will crash since the title pane is using the buffer. But surely if you change the title you must delete the old since you allocated it? Nope, Avkon will do that for you.

    Great example of things going wrong. They probably hadn't heard about "allocated memory should never be freed in another DLL" and that kind of stuff either...

  • group buy seo (unregistered)

    Immigration… [...]the time to read or visit the content or sites we have linked to below the[...]…group buy seo

Leave a comment on “Mr. Memory Leak”

Log In or post as a guest

Replying to comment #:

« Return to Article