Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > malloc trouble

Reply
Thread Tools

malloc trouble

 
 
Mike Wahler
Guest
Posts: n/a
 
      10-07-2005

"Christopher Benson-Manica" <(E-Mail Removed)> wrote in message
news:di64j0$ig8$(E-Mail Removed)...
> ncf <(E-Mail Removed)> wrote:
>
>> Alrighty, I just checked one comp.lang.c faq (located at
>> http://www.faqs.org/faqs/C-faq/faq/), and to be quite honest, the code
>> they're using is making little sense to me, but I will give it a shot.

>
> It is proper Usenet etiquette to include the text you are replying to.
> To do this using Google groups, please follow the instructions below,
> penned by Keith Thompson:
>
> 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.
>
>> if ( (messages[num_messages] = (char
>> *)malloc((size_t)BUFFLEN))

>
> It isn't in the FAQ, but should be: Casting the return of malloc() is
> both unnecessary and inadvisable.


http://www.eskimo.com/~scs/C-faq/q7.6.html
http://www.eskimo.com/~scs/C-faq/q7.7.html

These don't go into much detail, but they're in there.

-Mike


 
Reply With Quote
 
 
 
 
Flash Gordon
Guest
Posts: n/a
 
      10-07-2005
Niklas Norrthon wrote:
> "ncf" <(E-Mail Removed)> writes:


<snip>

>>/*
>> * malloc/realloc/free test
>> */
>>#include <string.h>
>>#include <stdio.h>
>>#include <stdlib.h>
>>
>>#define BUFFLEN 10
>>
>>char **messages;

>
> char **messages = NULL; /* initalize, so we can use realloc from start */


It's declared at file scope so it will be initialised to a null pointer
anyway. However, if the variables were moved in to main (which would be
better style since using globals where they are not needed is bad style
and a very bad habit, then it would need initialising.

>>int num_messages=0;
>>
>>int main(int argc, char **argv) {

>
> int main(void) { /* here we don't use command line arguments, so void
> eliminates a couple of warnings */


<snip>

> return EXIT_FAILURE; /* Only defined return codes from main are
> 0, EXIT_OK, and EXIT_FAILURE */


I think you mean EXIT_SUCCESS rather than EXIT_OK. It should also be
noted that returning 0 is defined as meaning success.

<snip>
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
 
Reply With Quote
 
 
 
 
Christopher Benson-Manica
Guest
Posts: n/a
 
      10-07-2005
Mike Wahler <(E-Mail Removed)> wrote:

> http://www.eskimo.com/~scs/C-faq/q7.6.html
> http://www.eskimo.com/~scs/C-faq/q7.7.html


> These don't go into much detail, but they're in there.


I'm aware of those, but neither explicitly says "don't do it", which
is a sentence that needs to be culled from the thousands of posts on
the subject and enshrined in the FAQ

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
 
Reply With Quote
 
ncf
Guest
Posts: n/a
 
      10-07-2005
Alrighty, yea, I didn't know how to reply w/ quoting for a bit out of
my own stupidity, but thanks for pointing out how ;P

I'll keep it in mind not to cast malloc()'s return

Thanks

Christopher Benson-Manica wrote:
> ncf <(E-Mail Removed)> wrote:
>
> > Alrighty, I just checked one comp.lang.c faq (located at
> > http://www.faqs.org/faqs/C-faq/faq/), and to be quite honest, the code
> > they're using is making little sense to me, but I will give it a shot.

>
> It is proper Usenet etiquette to include the text you are replying to.
> To do this using Google groups, please follow the instructions below,
> penned by Keith Thompson:
>
> 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.
>
> > if ( (messages[num_messages] = (char *)malloc((size_t)BUFFLEN))

>
> It isn't in the FAQ, but should be: Casting the return of malloc() is
> both unnecessary and inadvisable. Read this group's archives for
> details.
>
> --
> Christopher Benson-Manica | I *should* know what I'm talking about - if I
> ataru(at)cyberspace.org | don't, I need to know. Flames welcome.


 
Reply With Quote
 
ncf
Guest
Posts: n/a
 
      10-08-2005
Flash Gordon wrote:
> However, if the variables were moved in to main (which would be
> better style since using globals where they are not needed is bad style
> and a very bad habit, then it would need initialising.


The code I'm working with right now has messages and num_messages in
the file scope because I'm going to be integrating the concepts/product
of this efforts into a larger thing that I'm trying to do, so IMHO,
it's ok in this case if those two were defined global.


> > return EXIT_FAILURE; /* Only defined return codes from main are
> > 0, EXIT_OK, and EXIT_FAILURE */

>
> I think you mean EXIT_SUCCESS rather than EXIT_OK. It should also be
> noted that returning 0 is defined as meaning success.


What's the big diff between EXIT_FAILURE and 1?! I mean, returning 1
just means generic error in the first place....

-Wes

 
Reply With Quote
 
ncf
Guest
Posts: n/a
 
      10-08-2005
Michael Mair wrote:
> > Hmm...how would I do the realloc later then if the space was never
> > alloc'd? Or would that be unnecessary as well? :slightly confused:

>
> realloc(NULL, size) does the same thing as malloc(size),
> realloc(ptr, 0) does the same thing as free(ptr).
> Your implementation typically comes with a standard library
> reference which you should look into; if not, try the C99
> library reference on dinkumware.com

Hmm...interesting to know. Thank you for expanding and explaining. I
was always just working off of man pages (`man 3 malloc' and the like)



> > Hmm...I *think* I see what you're saying. By memory leak, I'm infering
> > that you mean memory that was never free()d for other applications to
> > use.

>
> Yes and no. It may be also memory _you_ cannot use later on in
> your program because you already allocated but sort of lost the
> key to use it. If you need large amounts of memory this may be
> the bit which makes your program exit earlier than planned due
> to (self-inflicted) lack of memory...
> As an aside, most modern operating systems clean up after an
> application finished, so many well-known applications accept
> that there are memory leaks in their code that could not be
> tracked down. This is bad practice and may hide other errors
> which then come down as soon as some minor detail changes. Just
> avoid them

Hehe, thanks for expanding


> > Hmm...I'm not too sure right now how it'd hide errors, but hey! It'll
> > make sense probably later on, so lets not worry too much about that.
> > I'll just take your word for it

>
> For one, it is not necessary. The other thing is that casts
> are pretty strong: They tell the compiler to shut up.
> In combination with the "implicit int" rule, this may shadow
> the fact that you forgot to #include <stdlib.h> which in turn
> can lead to odd effects if sizeof(int) is different from the
> size of the respective pointer type you cast to -- it may go
> well 99% of the time but every now and then, you have your
> program eating your hard disc's contents or similar...

Ooh, prog eating my HD eh? Sounds like something I've done before in
Bash (accidently recursively deleted /usr/bin)


> My, you _really_ have promise

Not really sure what you mean by "you _really_ have promise", but uhh,
ok (bad grammar constructs seem to make me get all confused easily)


Have a GREAT one

 
Reply With Quote
 
Mike Wahler
Guest
Posts: n/a
 
      10-08-2005

"ncf" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
> Flash Gordon wrote:
>> However, if the variables were moved in to main (which would be
>> better style since using globals where they are not needed is bad style
>> and a very bad habit, then it would need initialising.

>
> The code I'm working with right now has messages and num_messages in
> the file scope because I'm going to be integrating the concepts/product
> of this efforts into a larger thing that I'm trying to do, so IMHO,
> it's ok in this case if those two were defined global.
>
>
>> > return EXIT_FAILURE; /* Only defined return codes from main are
>> > 0, EXIT_OK, and EXIT_FAILURE */

>>
>> I think you mean EXIT_SUCCESS rather than EXIT_OK. It should also be
>> noted that returning 0 is defined as meaning success.

>
> What's the big diff between EXIT_FAILURE and 1?!


EXIT_FAILURE is portable, 1 is not.
Standard C defines exactly three values for the return
value of main:

EXIT_SUCCESS
EXIT_FAILURE
zero (0) (or any integer expression which evaluates to zero)

0 also means 'success', but note that its actual value
need not be zero (but it often is).

> I mean, returning 1
> just means generic error in the first place....


Not in standard C it doesn't. The language doesn't give
it any meaning at all as the return value from 'main()'
(although some implementations might as an 'extension').

-Mike



 
Reply With Quote
 
ncf
Guest
Posts: n/a
 
      10-08-2005
Mike Wahler wrote:
> > What's the big diff between EXIT_FAILURE and 1?!

>
> EXIT_FAILURE is portable, 1 is not.
> Standard C defines exactly three values for the return
> value of main:
>
> EXIT_SUCCESS
> EXIT_FAILURE
> zero (0) (or any integer expression which evaluates to zero)
>
> 0 also means 'success', but note that its actual value
> need not be zero (but it often is).
>
> > I mean, returning 1
> > just means generic error in the first place....

>
> Not in standard C it doesn't. The language doesn't give
> it any meaning at all as the return value from 'main()'
> (although some implementations might as an 'extension').



Interesting. Well, I'll definately try to keep that in mind as I
continue into learning. I've just always used 0 or 1 as it just seems
to be somewhat conventional (like for sh scripts and the like).

-Wes

 
Reply With Quote
 
Mike Wahler
Guest
Posts: n/a
 
      10-08-2005

"ncf" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
> Mike Wahler wrote:
>> > What's the big diff between EXIT_FAILURE and 1?!

>>
>> EXIT_FAILURE is portable, 1 is not.
>> Standard C defines exactly three values for the return
>> value of main:
>>
>> EXIT_SUCCESS
>> EXIT_FAILURE
>> zero (0) (or any integer expression which evaluates to zero)
>>
>> 0 also means 'success', but note that its actual value
>> need not be zero (but it often is).


What I meant to say here is that although both
zero and 'EXIT_SUCCESS' designate 'successful
completion', the value of 'EXIT_SUCCESS' may
or may not be zero.

(Also note that even if main() returns zero, that
need not be the value received by the calling
environment. The implementation might translate
it to something more meaningful to that environment).

-Mike


 
Reply With Quote
 
ncf
Guest
Posts: n/a
 
      10-08-2005
Interesting concept. Well, thanks so much for the pointer on that.
-Wes

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
to malloc or not to malloc?? Johs32 C Programming 4 03-30-2006 10:03 AM
porting non-malloc code to malloc micromysore@gmail.com C Programming 3 02-19-2005 05:39 AM
Malloc/Free - freeing memory allocated by malloc Peter C Programming 34 10-22-2004 10:23 AM
free'ing malloc'd structure with malloc'd members John C Programming 13 08-02-2004 11:45 AM
Re: free'ing malloc'd structure with malloc'd members ravi C Programming 0 07-30-2004 12:42 PM



Advertisments