Re: allocate memory statically

Discussion in 'C Programming' started by E. Robert Tisdale, Feb 8, 2005.

  1. Janice wrote:

    > if we allocate memory the following way, it will cause memory leak.
    >
    > char* func(void){
    > return (char*)malloc(10);
    > }
    >
    > int main(int argc, char* argv[]) {
    > char* ptr = func();

    free((void*)ptr); // fixes memory leak
    return 0;
    > }
    >
    > How to allocate the memory statically?


    typedef struct charArray10 {
    char Array[10];
    } charArray10;

    charArray10 func(void) {
    charArray10 result;
    // initialize result
    return result;
    }

    int main(int argc, char* argv[]) {
    charArray10 a = func();
    // use charArray10 a
    return 0;
    }
     
    E. Robert Tisdale, Feb 8, 2005
    #1
    1. Advertising

  2. "E. Robert Tisdale" <> writes:
    > Janice wrote:
    >
    >> if we allocate memory the following way, it will cause memory leak.
    >> char* func(void){
    >> return (char*)malloc(10);
    >> }
    >> int main(int argc, char* argv[]) {
    >> char* ptr = func();

    > free((void*)ptr); // fixes memory leak
    > return 0;

    [snip]

    Don't you mean

    char *ptr = (char*)func();
    (void)free((void*)(char*)ptr);
    return (int)0;

    ? I mean, as long as you're inserting useless casts, why stop?

    Or you could just write

    free(ptr);

    like most of us do.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Feb 9, 2005
    #2
    1. Advertising

  3. Keith Thompson wrote:

    > E. Robert Tisdale writes:
    >
    >>Janice wrote:
    >>
    >>>if we allocate memory the following way, it will cause memory leak.
    >>> char* func(void){
    >>> return (char*)malloc(10);
    >>> }
    >>> int main(int argc, char* argv[]) {
    >>> char* ptr = func();

    >>
    >> free((void*)ptr); // fixes memory leak
    >> return 0;

    >
    > Don't you mean
    >
    > char *ptr = (char*)func();
    > (void)free((void*)(char*)ptr);
    > return (int)0;
    >
    > ? I mean, as long as you're inserting useless casts, why stop?


    You are confused.
    func(void) returns a pointer to a character
    and your cast is redundant, superfluous and unnecessary
    in both C and C++ because no conversion is required.

    A conversion *is* required to initialize a non-void pointer

    char* p = malloc(10);

    implicitly. An *explicit* conversion is required

    char* p = (char*)malloc(10);

    to get my C++ compiler to shut up about it.

    > Or you could just write
    >
    > free(ptr);
    >
    > like most of us do.


    > cat main.c

    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>

    char* func(void) {
    const
    char* a = "Hello world!";
    return strcpy((char*)malloc(strlen(a) + 1), a);
    }

    int main(int argc, char* argv[]) {
    const
    char* s = func();
    FILE* myout = stdout;
    fprintf(myout, "%s\n", s);
    free(s);
    return 0;
    }

    > gcc -Wall -std=c99 -pedantic -o main main.c

    main.c: In function `main':
    main.c:16: warning: passing arg 1 of `free' \
    discards qualifiers from pointer target type
    > ./main

    Hello world!

    In order to get the compiler to shut up about this, I write

    free((void*)s);

    I have just made it a habit to *always* cast pointers to void*
    whether they are const or not
    because it makes my code easier to analyze --
    I don't need to consider whether the pointer is const or not --
    it doesn't matter if I'm going to delete it.
     
    E. Robert Tisdale, Feb 9, 2005
    #3
  4. "E. Robert Tisdale" <> writes:
    [snip]
    > A conversion *is* required to initialize a non-void pointer
    >
    > char* p = malloc(10);
    >
    > implicitly.


    Yes.

    > An *explicit* conversion is required
    >
    > char* p = (char*)malloc(10);


    Everybody knows this, and nobody cares.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Feb 9, 2005
    #4
  5. Keith Thompson <> writes:
    > "E. Robert Tisdale" <> writes:
    > [snip]
    >> A conversion *is* required to initialize a non-void pointer
    >>
    >> char* p = malloc(10);
    >>
    >> implicitly.

    >
    > Yes.
    >
    >> An *explicit* conversion is required
    >>
    >> char* p = (char*)malloc(10);

    >
    > Everybody knows this, and nobody cares.


    I made two mistakes here. First, I snipped too much relevant context.
    What ERT wrote was:

    > An *explicit* conversion is required
    >
    > char* p = (char*)malloc(10);
    >
    > to get my C++ compiler to shut up about it.


    Second, I tried to have a conversation with ERT.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Feb 9, 2005
    #5
  6. E. Robert Tisdale

    kenuplus Guest

    due to the void *malloc(unsigned size),there is no difference between
    char* p = malloc(10); and char* p =(char *) malloc(10);
     
    kenuplus, Feb 10, 2005
    #6
  7. On 10 Feb 2005 10:46:43 -0800, in comp.lang.c ,
    (kenuplus) wrote:

    >due to the void *malloc(unsigned size),there is no difference between
    > char* p = malloc(10); and char* p =(char *) malloc(10);


    Exactly. Except that the latter has an unnecessary cast, and may mask a
    serious error. So the cast should be omitted.

    If you want to learn more about why serious CLC'ers recommend avoiding
    casts, hang around here and you'll soon see.

    --
    Mark McIntyre
    CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
    CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
     
    Mark McIntyre, Feb 10, 2005
    #7
  8. Mark McIntyre wrote:

    > kenuplus wrote:
    >
    >>Due to the void *malloc(unsigned size), there is no difference
    >>between char* p = malloc(10); and char* p = (char*)malloc(10);

    >
    > Exactly. Except that the latter has an unnecessary cast


    No. The cast is necessary.
    It just isn't necessary to convert a void* to a char* *explicitly*
    in C because an *implicit* conversion is invoked by default.
    C++ does *not* specify any such implicit conversion
    so an explicit conversion is required in C++.

    > and may mask a serious error.
    > So the cast should be omitted.


    This may be true for inferior or obsolete C compilers
    but modern quality ANSI/ISO C99 compliant compiler
    will issue a diagnostic message if malloc(size_t) has not been declared.

    > If you want to learn more
    > about why serious CLC'ers recommend avoiding casts,
    > hang around here and you'll soon see.


    There is *no* good objective reason.
    It is merely a subjective style issue.
     
    E. Robert Tisdale, Feb 10, 2005
    #8
  9. E. Robert Tisdale

    infobahn Guest

    "E. Robert Tisdale" wrote:
    >
    > Mark McIntyre wrote:
    >
    > > kenuplus wrote:
    > >
    > >>Due to the void *malloc(unsigned size), there is no difference
    > >>between char* p = malloc(10); and char* p = (char*)malloc(10);

    > >
    > > Exactly. Except that the latter has an unnecessary cast

    >
    > No. The cast is necessary.


    Nonsense. It's superfluous, misleading, and can hide a bug.

    > It just isn't necessary to convert a void* to a char* *explicitly*


    Right. Saying this another way, "It just isn't necessary to cast".


    > in C because an *implicit* conversion is invoked by default.


    Hence you don't need a cast.

    > C++ does *not* specify any such implicit conversion


    SEP.
     
    infobahn, Feb 11, 2005
    #9
  10. E. Robert Tisdale

    suman kar Guest

    "E. Robert Tisdale" <> wrote in message news:<cugr4h$jqj$>...
    > Mark McIntyre wrote:
    >
    > > kenuplus wrote:
    > >
    > >>Due to the void *malloc(unsigned size), there is no difference
    > >>between char* p = malloc(10); and char* p = (char*)malloc(10);

    > >
    > > Exactly. Except that the latter has an unnecessary cast

    >
    > No. The cast is necessary.


    You did not specify any reasons for doing so.Probably that would have
    been more convinving.

    > It just isn't necessary to convert a void* to a char* *explicitly*
    > in C because an *implicit* conversion is invoked by default.


    So, you were talking about ~C in clc, I presume?

    > C++ does *not* specify any such implicit conversion
    > so an explicit conversion is required in C++.
    >


    More confusion for less seasoned posters like me here.Isn't this OT?

    > > and may mask a serious error.
    > > So the cast should be omitted.

    >
    > This may be true for inferior or obsolete C compilers
    > but modern quality ANSI/ISO C99 compliant compiler
    > will issue a diagnostic message if malloc(size_t) has not been declared.


    Diagnostics are the compiler's way of saying what Mr. McIntyre calls
    "serious error".I guess, once again.

    > > If you want to learn more
    > > about why serious CLC'ers recommend avoiding casts,
    > > hang around here and you'll soon see.

    >
    > There is *no* good objective reason.
    > It is merely a subjective style issue.


    Style issues are, AFAIK guided by years of experience and major
    setbacks(when not followed.)

    I would like to stand corrected, should need be.

    Regards,
    Suman.
     
    suman kar, Feb 11, 2005
    #10
  11. E. Robert Tisdale

    CBFalconer Guest

    "E. Robert Tisdale" wrote:
    > Mark McIntyre wrote:
    >> kenuplus wrote:
    >>
    >>> Due to the void *malloc(unsigned size), there is no difference
    >>> between char* p = malloc(10); and char* p = (char*)malloc(10);

    >>
    >> Exactly. Except that the latter has an unnecessary cast

    >
    > No. The cast is necessary.
    > It just isn't necessary to convert a void* to a char* *explicitly*
    > in C because an *implicit* conversion is invoked by default.
    > C++ does *not* specify any such implicit conversion
    > so an explicit conversion is required in C++.


    Warning to newbies - learn to recognize E. Robert Tisdales
    maundering and misinformation, and to ignore them. In this case
    Trollsdale is talking about a different language, i.e. C++, in a C
    newsgroup. His only purpose is to annoy. We have lost any hope
    that he will grow up into an adult.

    --
    "If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
     
    CBFalconer, Feb 11, 2005
    #11
  12. suman kar wrote:

    > E. Robert Tisdale wrote:
    >
    >>Mark McIntyre wrote:
    >>
    >>>kenuplus wrote:
    >>>
    >>>>Due to the void *malloc(unsigned size), there is no difference
    >>>>between char* p = malloc(10); and char* p = (char*)malloc(10);
    >>>
    >>>Exactly. Except that the latter has an unnecessary cast

    >>
    >>No. The cast is necessary.

    >
    > You did not specify any reasons for doing so.
    > Probably that would have been more convinving.
    >
    >
    >>It just isn't necessary to convert a void* to a char* *explicitly*
    >>in C because an *implicit* conversion is invoked by default.

    >
    > So, you were talking about ~C in clc, I presume?
    >
    >>C++ does *not* specify any such implicit conversion
    >>so an explicit conversion is required in C++.

    >
    > More confusion for less seasoned posters like me here.Isn't this OT?
    >
    >>>and may mask a serious error.
    >>>So the cast should be omitted.

    >>
    >>This may be true for inferior or obsolete C compilers
    >>but modern quality ANSI/ISO C99 compliant compiler
    >>will issue a diagnostic message if malloc(size_t) has not been declared.

    >
    > Diagnostics are the compiler's way of saying
    > what Mr. McIntyre calls "serious error". I guess, once again.


    McIntyre claims that C compilers will fail to issue any diagnostic
    if an explicit cast is applied to malloc(size_t).
    He is wrong and he knows it.

    >>>If you want to learn more
    >>>about why serious CLC'ers recommend avoiding casts,
    >>>hang around here and you'll soon see.

    >>
    >>There is *no* good objective reason.
    >>It is merely a subjective style issue.

    >
    > Style issues are, AFAIK guided
    > by years of experience and major setbacks(when not followed.)


    Unfortunately, style issues are sometimes formed from misconceptions
    as is the case here. They can persist only because
    they are justified by faulty but seductive reasoning.
    They crumble under critical analysis.

    > I would like to stand corrected, should need be.


    C is a "dead-end" language.
    The only future for C programs and C programmers is C++.
    This is why it is important for young C programmers
    to write C programs that are also valid C++ programs.
    Old C programmers are too "set in their ways"
    to learn the new programming language.
    Some old C programmers sabotage their C programs
    by including code that is incompatible with C++.
    Their programs will die when they die (or retire).
     
    E. Robert Tisdale, Feb 11, 2005
    #12
  13. E. Robert Tisdale

    infobahn Guest

    "E. Robert Tisdale" wrote:
    >
    > suman kar wrote:
    >
    > > Diagnostics are the compiler's way of saying
    > > what Mr. McIntyre calls "serious error". I guess, once again.

    >
    > McIntyre claims that C compilers will fail to issue any diagnostic
    > if an explicit cast is applied to malloc(size_t).
    > He is wrong and he knows it.


    I suspect it's more likely that he claims that *some* C compilers
    will fail to issue any diagnostic for the omission of <stdlib.h>
    if a cast is applied to malloc (btw "explicit cast" is redundant;
    all casts are explicit). It is certainly true that no C compiler
    is /obliged/ to issue a diagnostic under that circumstance, unless
    it conforms to C99 (which, apparently, none do yet).


    > Unfortunately, style issues are sometimes formed from misconceptions
    > as is the case here. They can persist only because
    > they are justified by faulty but seductive reasoning.
    > They crumble under critical analysis.


    That's more or less how I view your opinion, yes - it crumbles
    under the most cursory critical analysis (or indeed the deepest).

    > > I would like to stand corrected, should need be.

    >
    > C is a "dead-end" language.


    The fact that you think so says much more about you than it does
    about C.

    > The only future for C programs and C programmers is C++.


    Nonsense.

    > This is why it is important for young C programmers
    > to write C programs that are also valid C++ programs.


    It's stupid to write C programs that are also C++ programs.
    If you want C++, you know where to find it.

    > Old C programmers are too "set in their ways"
    > to learn the new programming language.


    Some of us "old" C programmers have learned C++ too, believe it
    or not. And we know when to use one, and when to use the other.

    > Some old C programmers sabotage their C programs
    > by including code that is incompatible with C++.


    That's not sabotage. It's a common sense safeguard to protect
    against accidentally compiling C programs under C++ rules. If
    such programmers wish to write C++ programs, they will do so.

    > Their programs will die when they die (or retire).


    Or not. That depends on many other factors, but /not/ the
    programming language.
     
    infobahn, Feb 11, 2005
    #13
  14. E. Robert Tisdale

    Chris Hills Guest

    In article <cuisrh$mh1$>, E. Robert Tisdale
    <> writes
    >
    >C is a "dead-end" language.


    C is the main language for embedded work and it's use is expanding
    (there are a lot more embedded systems year on year)

    >The only future for C programs and C programmers is C++.


    Actually no. In fact C++ will have a shorter life span. There are other
    languages that can and are replacing C++. However nothing is replacing C
    in the expanding embedded market.

    >This is why it is important for young C programmers
    >to write C programs that are also valid C++ programs.


    This is disastrous advice. C is no longer a subset of C++. If you learn
    C in the way you suggest it will turn out poor C++ programmers. It
    matters less for desktop use but most embedded work (where C is THE
    language and there is often no C++ compiler) is high-integrity, safety
    of mission critical. C should be taught and used as C not a cut down C++

    >Old C programmers are too "set in their ways"
    >to learn the new programming language.


    Really? Any evidence of this?

    >Some old C programmers sabotage their C programs
    >by including code that is incompatible with C++.


    C and C++ are different languages. C++ now has parts that are not
    compatible with C. We discussed this on the ISO C panel. If you want C
    and C++ compatibility then C++ will have to move closer to C.

    >Their programs will die when they die (or retire).


    This is silly. Embedded systems have 20+ years life-span. C just goes on
    and on. BTW many of the most common MCU on the planet dont have C++
    compilers.



    /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
    /\/\/ www.phaedsys.org \/\/
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
     
    Chris Hills, Feb 12, 2005
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Roedy Green
    Replies:
    3
    Views:
    3,301
    Roedy Green
    Aug 14, 2003
  2. sks_cpp
    Replies:
    7
    Views:
    403
    Jerry Coffin
    Jul 4, 2003
  3. Curt
    Replies:
    37
    Views:
    1,224
    Alexander Terekhov
    Jul 26, 2003
  4. OlgaM
    Replies:
    1
    Views:
    445
    Mike Wahler
    Oct 10, 2003
  5. Replies:
    5
    Views:
    665
    Matt Wharton
    Dec 9, 2004
Loading...

Share This Page