Memory management



  •  As in C, memory management is "complicated", and as we use a lot of dynamically allocated arrays, some team provided us with memory management functions. Including the following: 

     

    void IncreaseArray(void **pArray, bool *pIsAllocated, size_t Size){

        *pIsAllocated = false;

        if(*pArray){

            *pArray = realloc(*pArray,Size);

        }

        else{

            *pArray = malloc(Size);

        }

        if(*pArray){

            *pIsAllocated = true;

        }

     }

     

    Then, they will complain about memory leaks...

     



  • Wft is the purpose of this method? Calling Realloc with a null pointer is perfectly safe and defined(it allocates the memmory as requested).

    And calling free on the result from malloc/realloc is also always safe even if they return null, so that plsAllocated is not needed at all.(Just check for a null pointer, if you really want to know if your allocation failed). 

    It might just be me who haven't used low level c allocaters in a while(Got c++ classes to handle that) but I don't se how this leaks memmory.  Only leak is if realloc fails, but in that case you have bigger problems. 




  •  Yeah, I guess I have bigger problems indeed.



  • From a quick look at realloc, it may or may not return a pointer to the same allocated memory.[1] If the call to realloc returns a new pointer to a new memory allocation, then the old memory allocation has no pointer, and is not released properly (unless the caller handles it).

    As a function that is supposed to reduce the burden of memory management, this one isn't very good at all. The following code validates/invalidates my right to an opinion:

    void IncreaseArray(void **pArray, bool *pIsAllocated, size_t Size){



     *pIsAllocated = false;


     if(*pArray){

      void *pTemp = *pArray;

      *pTemp = realloc(*pTemp,Size);

      if(*pTemp){

       *pIsAllocated = true;

       free(pArray);

       pArray = pTemp;

       }

     }

     else{

      *pArray = malloc(Size);

      if(*pArray){

       *pIsAllocated = true;

       }

     }

    }


  • ♿ (Parody)

    @Evilweasil said:

    If the call to realloc returns a new pointer to a new memory allocation, then the old memory allocation has no pointer, and is not released properly (unless the caller handles it).

    Is this some nonstandard version of realloc that you're talking about? OTOH, you've created TRWTF there in your proposed function, so thanks for the laugh.

    Or...IHBT? It's so hard to tell here...



  • @mt@ilovefactory.com said:

    Wft is the purpose of this method?
    By the looks of it, trying to (re)allocate a block of memory and putting in a separate boolean whether the returned block is null. Which would have been possible by actually checking whether the returned block is null.

     


  • Discourse touched me in a no-no place

    @Evilweasil said:

    If the call to realloc returns a new pointer to a new memory allocation, then the old memory allocation has no pointer, and is not released properly (unless the caller handles it).

    You appear to be under the impression that realloc() doesn't free the old block if a new block is allocated. Your impression is wrong.

    @Evilweasil said:

    <god-awful code>
    Your implementation of realloc() fails in (at least) two ways:

    1. it doesn't copy the contents of the old block of memory to the new block
    2. it always assigns a new block of memory, even in the cases where realloc() wouldn't. (e.g. if the block is smaller, the same size, or could fit in the current position with an extension.)


  • @PJH said:

    @Evilweasil said:
    If the call to realloc returns a new pointer to a new memory allocation, then the old memory allocation has no pointer, and is not released properly (unless the caller handles it).

    You appear to be under the impression that realloc() doesn't free the old block if a new block is allocated. Your impression is wrong.

    @Evilweasil said:

    <god-awful code>
    Your implementation of realloc() fails in (at least) two ways:

    1. it doesn't copy the contents of the old block of memory to the new block
    2. it always assigns a new block of memory, even in the cases where realloc() wouldn't. (e.g. if the block is smaller, the same size, or could fit in the current position with an extension.)

    I would fall back on the reliable defense of "I don't use C much" but that seems to go without saying here.



  • @Evilweasil said:

    I would fall back on the reliable defense of "I don't use C much" but that seems to go without saying here.

    Because it's only in C that you would expect a function which reallocates a chunk of memory to return a chunk of memory with the same data in it...



  • It's twenty-fucking thirteen. Can we stop micromanaging memory like we haven't had to micromanage registers since about 2000?

    (Comment rescinded if this is an embedded device with no filesystem)



  • @MiffTheFox said:

    fucking thirteen
    Giggity giggity



  • @MiffTheFox said:

    It's twenty-fucking thirteen. Can we stop micromanaging memory ...
    I agree, but straight C malloc/delete is a paradigm that just refuses to die, many have tried to kill it, most should have succeeded, but its still here shambling along like the undead!

    @MiffTheFox said:

    (Comment rescinded if this is an embedded device with no filesystem)
    Have you looked at the new C++11 features? I think C++ would benefit embedded situations greatly. Now if you had hard real-time requirements, you can't even use free-store allocations ... so yeah, C++ still wins.



  • @esoterik said:

    I agree, but straight C malloc/delete is a paradigm that just refuses to die, many have tried to kill it, most should have succeeded, but its still here shambling along like the undead!

    Java almost won but was historically slow (and now using it will let Oracle sue you), the CLR's not going anywhere because it has the eeeeviiiilllll of Microsoft attached to it, and nobody knows how to create a decent cross-platform scripting environment. JavaScript is coming close to being the programming language that will replace C++ for "this runs on fucking everything" though.



  • @MiffTheFox said:

    @esoterik said:
    I agree, but straight C malloc/delete is a paradigm that just refuses to die, many have tried to kill it, most should have succeeded, but its still here shambling along like the undead!

    Java almost won but was historically slow (and now using it will let Oracle sue you), the CLR's not going anywhere because it has the eeeeviiiilllll of Microsoft attached to it, and nobody knows how to create a decent cross-platform scripting environment. JavaScript is coming close to being the programming language that will replace C++ for "this runs on fucking everything" though.

    Go check out Python and Scala on MIPS.


  • @Ben L. said:

    @MiffTheFox said:
    @esoterik said:
    I agree, but straight C malloc/delete is a paradigm that just refuses to die, many have tried to kill it, most should have succeeded, but its still here shambling along like the undead!

    Java almost won but was historically slow (and now using it will let Oracle sue you), the CLR's not going anywhere because it has the eeeeviiiilllll of Microsoft attached to it, and nobody knows how to create a decent cross-platform scripting environment. JavaScript is coming close to being the programming language that will replace C++ for "this runs on fucking everything" though.

    Go check out Python and Scala on MIPS.

    Go seems promising although it's main problem is one of inertia at the moment. Maybe if Google dogfooded it people would be using it, but AFICT Google's almost all C++, Java, and JavaScript still (at least the external bits like Android and Chrome).

    Python for Windows feels like a bad port (but is getting better), and IronPython (the other main impl for Windows) runs on the CLR and thus is obviously an eeeeviiiilllll Mircosoft plot to destroy Python.

    I've never even heard of Scala so it's something I'll be checking out.



  • @MiffTheFox said:

    It's twenty-fucking thirteen.

     

    Nope, sorry, not here. We're still in twenty-0-somethin'. Not far ago, the code was still in assembler (hopefully, I was not here). I think the most recent tool we use (in-house tools excluded) is from 2008 and it's Lotus Notes. The compilers we use are from 2006.

     

     


  • Discourse touched me in a no-no place

    @Evilweasil said:

    The following code validates/invalidates my right to an opinion:
    FTFY. Good thing you covered both bases there...



  • @dkf said:

    @Evilweasil said:
    The following code validates/invalidates my right to an opinion:
    FTFY. Good thing you covered both bases there...

    We all know by now that general helpfulness is how I stay employed.

    Would you like me to get you some coffee?



  • @esoterik said:

    straight C malloc/delete is a paradigm that just refuses to die

    That's unfortunate, since straight C malloc/free is a paradigm that isn't all that difficult, and is actually correct.


Log in to reply