malloc trouble

[ncf]

Hi all.

In another topic, I was informed that I had to dynamically allocate
memory instead of just trying to expand on a list. (I'm trying to learn
C, and have a strong background in PHP and Python) In light of that, I
have been trying to learn malloc, realloc, and free, but to no avail.

But for some reason, I'm getting segfaults right and left, and to be
honest, I am not having any luck at all really in finding out why it
isn't working. However, I have traced it and discovered that the
malloc() call is what is causing the problem. (traced by adding various
printf()s and then moving the malloc to it's own line)

It would be greatly appreciated if anyone can point out what the heck
I'm doing so wrong. Code snipplets are included at the end of this
message.

Thank you soo much in advance.

-Wes

/* at the "file" level */
#define BUFFLEN 100
char **messages;
int num_messages=0;
/* inside of main() */
if ( (messages[num_messages] = (char *)malloc((size_ t)BUFFLEN))
==NULL)
{
printf("Could not allocate space.\n");
return 1;
}

[Mike Wahler]

"Christophe r Benson-Manica" <at***@nospam.c yberspace.org> wrote in message
news:di******** **@chessie.cirr .com...

ncf <no************ ***@gmail.com> 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.c om, 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

[Christopher Benson-Manica]

Mike Wahler <mk******@mkwah ler.net> 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)cybers pace.org | don't, I need to know. Flames welcome.

[Flash Gordon]

Niklas Norrthon wrote:

"ncf" <no************ ***@gmail.com> 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.

[ncf]

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 <no************ ***@gmail.com> 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.c om, 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)cybers pace.org | don't, I need to know. Flames welcome.

[ncf]

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

[ncf]

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...interesti ng 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) :roll:

My, you _really_ have promise ;-)

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

[Mike Wahler]

"ncf" <no************ ***@gmail.com> wrote in message
news:11******** **************@ o13g2000cwo.goo glegroups.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

[ncf]

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

[Mike Wahler]

"ncf" <no************ ***@gmail.com> wrote in message
news:11******** **************@ g14g2000cwa.goo glegroups.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

[ncf]

Interesting concept. Well, thanks so much for the pointer on that. :)
-Wes