malloc in main() or malloc in another function: allocating memory for a struct and its members Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern) Announcing the arrival of Valued Associate #679: Cesar Manara Unicorn Meta Zoo #1: Why another podcast?Allocating memory for a matrix with a single mallocPointers for struct and `for`Allocating memory and releasing the sameEdge cases for simulated malloc functiongetline substitute that will enforce 'n' as limit of characters readAllocating a contiguous block of memory for an arrayA pointer that stores its size at the frontDeletion of Word from Ternary Search Tree where Both Siblings PresentObject pool for allocating generic objects in aligned memorymalloc() and free() for Linux with system calls

Constant factor of an array

Does the Mueller report show a conspiracy between Russia and the Trump Campaign?

Is there hard evidence that the grant peer review system performs significantly better than random?

Can you force honesty by using the Speak with Dead and Zone of Truth spells together?

Why is a lens darker than other ones when applying the same settings?

Special flights

"klopfte jemand" or "jemand klopfte"?

Trying to understand entropy as a novice in thermodynamics

Flight departed from the gate 5 min before scheduled departure time. Refund options

Caught masturbating at work

malloc in main() or malloc in another function: allocating memory for a struct and its members

Why not use the yoke to control yaw, as well as pitch and roll?

Nose gear failure in single prop aircraft: belly landing or nose-gear up landing?

Sally's older brother

How many time has Arya actually used Needle?

Project Euler #1 in C++

Mounting TV on a weird wall that has some material between the drywall and stud

Central Vacuuming: Is it worth it, and how does it compare to normal vacuuming?

What is the difference between a "ranged attack" and a "ranged weapon attack"?

Can an iPhone 7 be made to function as a NFC Tag?

Is there any word for a place full of confusion?

Does the Black Tentacles spell do damage twice at the start of turn to an already restrained creature?

What initially awakened the Balrog?

The Nth Gryphon Number



malloc in main() or malloc in another function: allocating memory for a struct and its members



Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern)
Announcing the arrival of Valued Associate #679: Cesar Manara
Unicorn Meta Zoo #1: Why another podcast?Allocating memory for a matrix with a single mallocPointers for struct and `for`Allocating memory and releasing the sameEdge cases for simulated malloc functiongetline substitute that will enforce 'n' as limit of characters readAllocating a contiguous block of memory for an arrayA pointer that stores its size at the frontDeletion of Word from Ternary Search Tree where Both Siblings PresentObject pool for allocating generic objects in aligned memorymalloc() and free() for Linux with system calls



.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








1












$begingroup$


When initializing a struct in C, we can allocate memory inside the main function or within another function and return a pointer to the newly created struct. This first example shows the latter; memory is allocated in Buffer_create and a pointer is returned:



#include <stdio.h>
#include "buffer.h"

int main(int argc, char *argv[])

struct Buffer *tx_buffer = Buffer_create(8);

Buffer_destroy(tx_buffer);

return 0;



And this one shows how all memory allocations can be done within the main function:



#include <stdio.h>
#include "buffer.h"

int main(int argc, char *argv[])

uint8_t *ptr_rx_buffer = malloc(sizeof(uint8_t)*8);
struct Buffer *rx_buffer = malloc(sizeof(struct Buffer));
Buffer2_create(rx_buffer, ptr_rx_buffer, 8);

Buffer2_destroy(rx_buffer);

return 0;



And here are the contents of the header file buffer.h:



#ifndef _buffer_h
#define _buffer_h

#include <stdint.h>
#include <stdlib.h>

struct Buffer
uint8_t *buffer;
size_t size;
;

struct Buffer *Buffer_create(size_t size);

void Buffer_destroy(struct Buffer *who);

void Buffer2_create(struct Buffer *who, uint8_t *buffer, size_t size);

void Buffer2_destroy(struct Buffer *who);

#endif


And buffer.c:



#include <stdint.h>
#include <assert.h>
#include <stdlib.h>
#include "buffer.h"

struct Buffer *Buffer_create(size_t size)

struct Buffer *who = malloc(sizeof(struct Buffer));
assert(who != NULL);

who->buffer = malloc(sizeof(uint8_t)*size);
who->size = size;

return who;


void Buffer_destroy(struct Buffer *who)

assert(who != NULL);
free(who->buffer);
free(who);


void Buffer2_create(struct Buffer *who, uint8_t *buffer, size_t size)

assert(who != NULL);

who->buffer = buffer;
who->size = size;


void Buffer2_destroy(struct Buffer *who)

assert(who != NULL);
free(who->buffer);
free(who);



The Result



Both approaches work and the executable files for both end up being the same size.



My Question



Will either of these approaches result in memory leaks or poor performance?










share|improve this question









New contributor




David is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.







$endgroup$


















    1












    $begingroup$


    When initializing a struct in C, we can allocate memory inside the main function or within another function and return a pointer to the newly created struct. This first example shows the latter; memory is allocated in Buffer_create and a pointer is returned:



    #include <stdio.h>
    #include "buffer.h"

    int main(int argc, char *argv[])

    struct Buffer *tx_buffer = Buffer_create(8);

    Buffer_destroy(tx_buffer);

    return 0;



    And this one shows how all memory allocations can be done within the main function:



    #include <stdio.h>
    #include "buffer.h"

    int main(int argc, char *argv[])

    uint8_t *ptr_rx_buffer = malloc(sizeof(uint8_t)*8);
    struct Buffer *rx_buffer = malloc(sizeof(struct Buffer));
    Buffer2_create(rx_buffer, ptr_rx_buffer, 8);

    Buffer2_destroy(rx_buffer);

    return 0;



    And here are the contents of the header file buffer.h:



    #ifndef _buffer_h
    #define _buffer_h

    #include <stdint.h>
    #include <stdlib.h>

    struct Buffer
    uint8_t *buffer;
    size_t size;
    ;

    struct Buffer *Buffer_create(size_t size);

    void Buffer_destroy(struct Buffer *who);

    void Buffer2_create(struct Buffer *who, uint8_t *buffer, size_t size);

    void Buffer2_destroy(struct Buffer *who);

    #endif


    And buffer.c:



    #include <stdint.h>
    #include <assert.h>
    #include <stdlib.h>
    #include "buffer.h"

    struct Buffer *Buffer_create(size_t size)

    struct Buffer *who = malloc(sizeof(struct Buffer));
    assert(who != NULL);

    who->buffer = malloc(sizeof(uint8_t)*size);
    who->size = size;

    return who;


    void Buffer_destroy(struct Buffer *who)

    assert(who != NULL);
    free(who->buffer);
    free(who);


    void Buffer2_create(struct Buffer *who, uint8_t *buffer, size_t size)

    assert(who != NULL);

    who->buffer = buffer;
    who->size = size;


    void Buffer2_destroy(struct Buffer *who)

    assert(who != NULL);
    free(who->buffer);
    free(who);



    The Result



    Both approaches work and the executable files for both end up being the same size.



    My Question



    Will either of these approaches result in memory leaks or poor performance?










    share|improve this question









    New contributor




    David is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.







    $endgroup$














      1












      1








      1





      $begingroup$


      When initializing a struct in C, we can allocate memory inside the main function or within another function and return a pointer to the newly created struct. This first example shows the latter; memory is allocated in Buffer_create and a pointer is returned:



      #include <stdio.h>
      #include "buffer.h"

      int main(int argc, char *argv[])

      struct Buffer *tx_buffer = Buffer_create(8);

      Buffer_destroy(tx_buffer);

      return 0;



      And this one shows how all memory allocations can be done within the main function:



      #include <stdio.h>
      #include "buffer.h"

      int main(int argc, char *argv[])

      uint8_t *ptr_rx_buffer = malloc(sizeof(uint8_t)*8);
      struct Buffer *rx_buffer = malloc(sizeof(struct Buffer));
      Buffer2_create(rx_buffer, ptr_rx_buffer, 8);

      Buffer2_destroy(rx_buffer);

      return 0;



      And here are the contents of the header file buffer.h:



      #ifndef _buffer_h
      #define _buffer_h

      #include <stdint.h>
      #include <stdlib.h>

      struct Buffer
      uint8_t *buffer;
      size_t size;
      ;

      struct Buffer *Buffer_create(size_t size);

      void Buffer_destroy(struct Buffer *who);

      void Buffer2_create(struct Buffer *who, uint8_t *buffer, size_t size);

      void Buffer2_destroy(struct Buffer *who);

      #endif


      And buffer.c:



      #include <stdint.h>
      #include <assert.h>
      #include <stdlib.h>
      #include "buffer.h"

      struct Buffer *Buffer_create(size_t size)

      struct Buffer *who = malloc(sizeof(struct Buffer));
      assert(who != NULL);

      who->buffer = malloc(sizeof(uint8_t)*size);
      who->size = size;

      return who;


      void Buffer_destroy(struct Buffer *who)

      assert(who != NULL);
      free(who->buffer);
      free(who);


      void Buffer2_create(struct Buffer *who, uint8_t *buffer, size_t size)

      assert(who != NULL);

      who->buffer = buffer;
      who->size = size;


      void Buffer2_destroy(struct Buffer *who)

      assert(who != NULL);
      free(who->buffer);
      free(who);



      The Result



      Both approaches work and the executable files for both end up being the same size.



      My Question



      Will either of these approaches result in memory leaks or poor performance?










      share|improve this question









      New contributor




      David is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.







      $endgroup$




      When initializing a struct in C, we can allocate memory inside the main function or within another function and return a pointer to the newly created struct. This first example shows the latter; memory is allocated in Buffer_create and a pointer is returned:



      #include <stdio.h>
      #include "buffer.h"

      int main(int argc, char *argv[])

      struct Buffer *tx_buffer = Buffer_create(8);

      Buffer_destroy(tx_buffer);

      return 0;



      And this one shows how all memory allocations can be done within the main function:



      #include <stdio.h>
      #include "buffer.h"

      int main(int argc, char *argv[])

      uint8_t *ptr_rx_buffer = malloc(sizeof(uint8_t)*8);
      struct Buffer *rx_buffer = malloc(sizeof(struct Buffer));
      Buffer2_create(rx_buffer, ptr_rx_buffer, 8);

      Buffer2_destroy(rx_buffer);

      return 0;



      And here are the contents of the header file buffer.h:



      #ifndef _buffer_h
      #define _buffer_h

      #include <stdint.h>
      #include <stdlib.h>

      struct Buffer
      uint8_t *buffer;
      size_t size;
      ;

      struct Buffer *Buffer_create(size_t size);

      void Buffer_destroy(struct Buffer *who);

      void Buffer2_create(struct Buffer *who, uint8_t *buffer, size_t size);

      void Buffer2_destroy(struct Buffer *who);

      #endif


      And buffer.c:



      #include <stdint.h>
      #include <assert.h>
      #include <stdlib.h>
      #include "buffer.h"

      struct Buffer *Buffer_create(size_t size)

      struct Buffer *who = malloc(sizeof(struct Buffer));
      assert(who != NULL);

      who->buffer = malloc(sizeof(uint8_t)*size);
      who->size = size;

      return who;


      void Buffer_destroy(struct Buffer *who)

      assert(who != NULL);
      free(who->buffer);
      free(who);


      void Buffer2_create(struct Buffer *who, uint8_t *buffer, size_t size)

      assert(who != NULL);

      who->buffer = buffer;
      who->size = size;


      void Buffer2_destroy(struct Buffer *who)

      assert(who != NULL);
      free(who->buffer);
      free(who);



      The Result



      Both approaches work and the executable files for both end up being the same size.



      My Question



      Will either of these approaches result in memory leaks or poor performance?







      performance c comparative-review memory-management pointers






      share|improve this question









      New contributor




      David is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.











      share|improve this question









      New contributor




      David is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      share|improve this question




      share|improve this question








      edited 33 mins ago









      1201ProgramAlarm

      3,7632925




      3,7632925






      New contributor




      David is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      asked 3 hours ago









      DavidDavid

      1093




      1093




      New contributor




      David is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.





      New contributor





      David is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






      David is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.




















          2 Answers
          2






          active

          oldest

          votes


















          3












          $begingroup$

          Looking at the performance, the two versions should perform just about identically. The second version has one less call/return, which can save a couple of CPU cycles, but if you have it multiple places in your code the additional code bytes and cache misses can overshadow that. Either way you probably won't notice a difference.



          Looking at readability and maintainability, the first version is much better. You know at a glance what it is doing (rather than looking at several lines to figure it all out), you won't forget any important steps, and error checking is much easier since most of it can be handled in one place (excepting the last check for successful creation of the buffer). Debugging can also be easier, since you can set a breakpoint on the creation or destruction functions if necessary.






          share|improve this answer









          $endgroup$




















            0












            $begingroup$

            In the first case, the caller is not given any control over allocation. This limits freedom and (therefore) performance: there is no control over the number of dynamic allocations or over which memory is used for what purpose, and there are limits on how the handle to the buffer can be stored (the returned pointer to Buffer must be kept around somehow, even if we would really just want to store the Buffer by value and avoid some unnecessary double-indirection).



            In the second case, the caller does have control, but Buffer2_destroy makes a very limiting assumption about how the memory was allocated so in the end the caller still has no choice. Of course by looking into the implementation details, one could see that simply not calling Buffer2_destroy enables some freedom again, but this would probably be considered a hack. All in all this approach violates the guideline "allocate and free memory in the same module, at the same level of abstraction", and doesn't get much in return.



            Practically what a user of some buffer may want to do is for example:



            • Having the Buffer as a local variable but its data malloc-ed.

            • Having the Buffer as a local variable and making its data refer to a local array.

            • Save the Buffer into some other struct or array (by value, not a pointer to a Buffer which then points to the data).

            • Using (part of) a static array as the data.

            • Various other such combinations..

            • Allocate both the buffer data and the instance of Buffer in the same allocation.

            Which is why a common advice is, where possible, do not allocate or deallocate memory, use memory supplied by the caller. This applies especially to performance-sensitive settings, where "secret malloc" is not appreciated, and custom allocators are commonly used.






            share|improve this answer









            $endgroup$













              Your Answer






              StackExchange.ifUsing("editor", function ()
              StackExchange.using("externalEditor", function ()
              StackExchange.using("snippets", function ()
              StackExchange.snippets.init();
              );
              );
              , "code-snippets");

              StackExchange.ready(function()
              var channelOptions =
              tags: "".split(" "),
              id: "196"
              ;
              initTagRenderer("".split(" "), "".split(" "), channelOptions);

              StackExchange.using("externalEditor", function()
              // Have to fire editor after snippets, if snippets enabled
              if (StackExchange.settings.snippets.snippetsEnabled)
              StackExchange.using("snippets", function()
              createEditor();
              );

              else
              createEditor();

              );

              function createEditor()
              StackExchange.prepareEditor(
              heartbeatType: 'answer',
              autoActivateHeartbeat: false,
              convertImagesToLinks: false,
              noModals: true,
              showLowRepImageUploadWarning: true,
              reputationToPostImages: null,
              bindNavPrevention: true,
              postfix: "",
              imageUploader:
              brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
              contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
              allowUrls: true
              ,
              onDemand: true,
              discardSelector: ".discard-answer"
              ,immediatelyShowMarkdownHelp:true
              );



              );






              David is a new contributor. Be nice, and check out our Code of Conduct.









              draft saved

              draft discarded


















              StackExchange.ready(
              function ()
              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f217807%2fmalloc-in-main-or-malloc-in-another-function-allocating-memory-for-a-struct-a%23new-answer', 'question_page');

              );

              Post as a guest















              Required, but never shown

























              2 Answers
              2






              active

              oldest

              votes








              2 Answers
              2






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes









              3












              $begingroup$

              Looking at the performance, the two versions should perform just about identically. The second version has one less call/return, which can save a couple of CPU cycles, but if you have it multiple places in your code the additional code bytes and cache misses can overshadow that. Either way you probably won't notice a difference.



              Looking at readability and maintainability, the first version is much better. You know at a glance what it is doing (rather than looking at several lines to figure it all out), you won't forget any important steps, and error checking is much easier since most of it can be handled in one place (excepting the last check for successful creation of the buffer). Debugging can also be easier, since you can set a breakpoint on the creation or destruction functions if necessary.






              share|improve this answer









              $endgroup$

















                3












                $begingroup$

                Looking at the performance, the two versions should perform just about identically. The second version has one less call/return, which can save a couple of CPU cycles, but if you have it multiple places in your code the additional code bytes and cache misses can overshadow that. Either way you probably won't notice a difference.



                Looking at readability and maintainability, the first version is much better. You know at a glance what it is doing (rather than looking at several lines to figure it all out), you won't forget any important steps, and error checking is much easier since most of it can be handled in one place (excepting the last check for successful creation of the buffer). Debugging can also be easier, since you can set a breakpoint on the creation or destruction functions if necessary.






                share|improve this answer









                $endgroup$















                  3












                  3








                  3





                  $begingroup$

                  Looking at the performance, the two versions should perform just about identically. The second version has one less call/return, which can save a couple of CPU cycles, but if you have it multiple places in your code the additional code bytes and cache misses can overshadow that. Either way you probably won't notice a difference.



                  Looking at readability and maintainability, the first version is much better. You know at a glance what it is doing (rather than looking at several lines to figure it all out), you won't forget any important steps, and error checking is much easier since most of it can be handled in one place (excepting the last check for successful creation of the buffer). Debugging can also be easier, since you can set a breakpoint on the creation or destruction functions if necessary.






                  share|improve this answer









                  $endgroup$



                  Looking at the performance, the two versions should perform just about identically. The second version has one less call/return, which can save a couple of CPU cycles, but if you have it multiple places in your code the additional code bytes and cache misses can overshadow that. Either way you probably won't notice a difference.



                  Looking at readability and maintainability, the first version is much better. You know at a glance what it is doing (rather than looking at several lines to figure it all out), you won't forget any important steps, and error checking is much easier since most of it can be handled in one place (excepting the last check for successful creation of the buffer). Debugging can also be easier, since you can set a breakpoint on the creation or destruction functions if necessary.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered 24 mins ago









                  1201ProgramAlarm1201ProgramAlarm

                  3,7632925




                  3,7632925























                      0












                      $begingroup$

                      In the first case, the caller is not given any control over allocation. This limits freedom and (therefore) performance: there is no control over the number of dynamic allocations or over which memory is used for what purpose, and there are limits on how the handle to the buffer can be stored (the returned pointer to Buffer must be kept around somehow, even if we would really just want to store the Buffer by value and avoid some unnecessary double-indirection).



                      In the second case, the caller does have control, but Buffer2_destroy makes a very limiting assumption about how the memory was allocated so in the end the caller still has no choice. Of course by looking into the implementation details, one could see that simply not calling Buffer2_destroy enables some freedom again, but this would probably be considered a hack. All in all this approach violates the guideline "allocate and free memory in the same module, at the same level of abstraction", and doesn't get much in return.



                      Practically what a user of some buffer may want to do is for example:



                      • Having the Buffer as a local variable but its data malloc-ed.

                      • Having the Buffer as a local variable and making its data refer to a local array.

                      • Save the Buffer into some other struct or array (by value, not a pointer to a Buffer which then points to the data).

                      • Using (part of) a static array as the data.

                      • Various other such combinations..

                      • Allocate both the buffer data and the instance of Buffer in the same allocation.

                      Which is why a common advice is, where possible, do not allocate or deallocate memory, use memory supplied by the caller. This applies especially to performance-sensitive settings, where "secret malloc" is not appreciated, and custom allocators are commonly used.






                      share|improve this answer









                      $endgroup$

















                        0












                        $begingroup$

                        In the first case, the caller is not given any control over allocation. This limits freedom and (therefore) performance: there is no control over the number of dynamic allocations or over which memory is used for what purpose, and there are limits on how the handle to the buffer can be stored (the returned pointer to Buffer must be kept around somehow, even if we would really just want to store the Buffer by value and avoid some unnecessary double-indirection).



                        In the second case, the caller does have control, but Buffer2_destroy makes a very limiting assumption about how the memory was allocated so in the end the caller still has no choice. Of course by looking into the implementation details, one could see that simply not calling Buffer2_destroy enables some freedom again, but this would probably be considered a hack. All in all this approach violates the guideline "allocate and free memory in the same module, at the same level of abstraction", and doesn't get much in return.



                        Practically what a user of some buffer may want to do is for example:



                        • Having the Buffer as a local variable but its data malloc-ed.

                        • Having the Buffer as a local variable and making its data refer to a local array.

                        • Save the Buffer into some other struct or array (by value, not a pointer to a Buffer which then points to the data).

                        • Using (part of) a static array as the data.

                        • Various other such combinations..

                        • Allocate both the buffer data and the instance of Buffer in the same allocation.

                        Which is why a common advice is, where possible, do not allocate or deallocate memory, use memory supplied by the caller. This applies especially to performance-sensitive settings, where "secret malloc" is not appreciated, and custom allocators are commonly used.






                        share|improve this answer









                        $endgroup$















                          0












                          0








                          0





                          $begingroup$

                          In the first case, the caller is not given any control over allocation. This limits freedom and (therefore) performance: there is no control over the number of dynamic allocations or over which memory is used for what purpose, and there are limits on how the handle to the buffer can be stored (the returned pointer to Buffer must be kept around somehow, even if we would really just want to store the Buffer by value and avoid some unnecessary double-indirection).



                          In the second case, the caller does have control, but Buffer2_destroy makes a very limiting assumption about how the memory was allocated so in the end the caller still has no choice. Of course by looking into the implementation details, one could see that simply not calling Buffer2_destroy enables some freedom again, but this would probably be considered a hack. All in all this approach violates the guideline "allocate and free memory in the same module, at the same level of abstraction", and doesn't get much in return.



                          Practically what a user of some buffer may want to do is for example:



                          • Having the Buffer as a local variable but its data malloc-ed.

                          • Having the Buffer as a local variable and making its data refer to a local array.

                          • Save the Buffer into some other struct or array (by value, not a pointer to a Buffer which then points to the data).

                          • Using (part of) a static array as the data.

                          • Various other such combinations..

                          • Allocate both the buffer data and the instance of Buffer in the same allocation.

                          Which is why a common advice is, where possible, do not allocate or deallocate memory, use memory supplied by the caller. This applies especially to performance-sensitive settings, where "secret malloc" is not appreciated, and custom allocators are commonly used.






                          share|improve this answer









                          $endgroup$



                          In the first case, the caller is not given any control over allocation. This limits freedom and (therefore) performance: there is no control over the number of dynamic allocations or over which memory is used for what purpose, and there are limits on how the handle to the buffer can be stored (the returned pointer to Buffer must be kept around somehow, even if we would really just want to store the Buffer by value and avoid some unnecessary double-indirection).



                          In the second case, the caller does have control, but Buffer2_destroy makes a very limiting assumption about how the memory was allocated so in the end the caller still has no choice. Of course by looking into the implementation details, one could see that simply not calling Buffer2_destroy enables some freedom again, but this would probably be considered a hack. All in all this approach violates the guideline "allocate and free memory in the same module, at the same level of abstraction", and doesn't get much in return.



                          Practically what a user of some buffer may want to do is for example:



                          • Having the Buffer as a local variable but its data malloc-ed.

                          • Having the Buffer as a local variable and making its data refer to a local array.

                          • Save the Buffer into some other struct or array (by value, not a pointer to a Buffer which then points to the data).

                          • Using (part of) a static array as the data.

                          • Various other such combinations..

                          • Allocate both the buffer data and the instance of Buffer in the same allocation.

                          Which is why a common advice is, where possible, do not allocate or deallocate memory, use memory supplied by the caller. This applies especially to performance-sensitive settings, where "secret malloc" is not appreciated, and custom allocators are commonly used.







                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered 14 mins ago









                          haroldharold

                          1,47368




                          1,47368




















                              David is a new contributor. Be nice, and check out our Code of Conduct.









                              draft saved

                              draft discarded


















                              David is a new contributor. Be nice, and check out our Code of Conduct.












                              David is a new contributor. Be nice, and check out our Code of Conduct.











                              David is a new contributor. Be nice, and check out our Code of Conduct.














                              Thanks for contributing an answer to Code Review Stack Exchange!


                              • Please be sure to answer the question. Provide details and share your research!

                              But avoid


                              • Asking for help, clarification, or responding to other answers.

                              • Making statements based on opinion; back them up with references or personal experience.

                              Use MathJax to format equations. MathJax reference.


                              To learn more, see our tips on writing great answers.




                              draft saved


                              draft discarded














                              StackExchange.ready(
                              function ()
                              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f217807%2fmalloc-in-main-or-malloc-in-another-function-allocating-memory-for-a-struct-a%23new-answer', 'question_page');

                              );

                              Post as a guest















                              Required, but never shown





















































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown

































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown







                              Popular posts from this blog

                              Disable / Remove link to Product Items in Cart Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern) Announcing the arrival of Valued Associate #679: Cesar Manara Unicorn Meta Zoo #1: Why another podcast?How can I limit products that can be bought / added to cart?Remove item from cartHide “Add to Cart” button if specific products are already in cart“Prettifying” the custom options in cart pageCreate link in cart sidebar to view all added items After limit reachedLink products together in checkout/cartHow to Get product from cart and add it againHide action-edit on cart page if simple productRemoving Cart items - ObserverRemove wishlist items when added to cart

                              Helsingin valtaus Sisällysluettelo Taustaa | Yleistä sotatoimista | Osapuolet | Taistelut Helsingin ympäristössä | Punaisten antautumissuunnitelma | Taistelujen kulku Helsingissä | Valtauksen jälkeen | Tappiot | Muistaminen | Kirjallisuutta | Lähteet | Aiheesta muualla | NavigointivalikkoTeoksen verkkoversioTeoksen verkkoversioGoogle BooksSisällissota Helsingissä päättyi tasan 95 vuotta sittenSaksalaisten ylivoima jyräsi punaisen HelsinginSuomalaiset kuvaavat sotien jälkiä kaupungeissa – katso kuvat ja tarinat tutuilta kulmiltaHelsingin valtaus 90 vuotta sittenSaksalaiset valtasivat HelsinginHyökkäys HelsinkiinHelsingin valtaus 12.–13.4. 1918Saksalaiset käyttivät ihmiskilpiä Helsingin valtauksessa 1918Teoksen verkkoversioTeoksen verkkoversioSaksalaiset hyökkäävät Etelä-SuomeenTaistelut LeppävaarassaSotilaat ja taistelutLeppävaara 1918 huhtikuussa. KapinatarinaHelsingin taistelut 1918Saksalaisten voitonparaati HelsingissäHelsingin valtausta juhlittiinSaksalaisten Helsinki vuonna 1918Helsingin taistelussa kaatuneet valkokaartilaisetHelsinkiin haudatut taisteluissa kaatuneet punaiset12.4.1918 Helsingin valtauksessa saksalaiset apujoukot vapauttavat kaupunginVapaussodan muistomerkkejä Helsingissä ja pääkaupunkiseudullaCrescendo / Vuoden 1918 Kansalaissodan uhrien muistomerkkim

                              Adjektiivitarina Tarinan tekeminen | Esimerkki: ennen | Esimerkki: jälkeen | Navigointivalikko