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;
}

[Michael Mair]

ncf wrote:

Michael Mair wrote:

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)

You not only took the advice and followed it but also
thanked the one giving it...

-Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Michael Mair]

Michael Mair wrote:

ncf wrote:

Michael Mair wrote:

My, you _really_ have promise ;-)

s/have/show/

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)

You not only took the advice and followed it but also
thanked the one giving it...

-Michael

--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Flash Gordon]

ncf wrote:

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.

IMHO if it will be integrated in to a larger project that is an even
bigger reason to *avoid* using globals. I'll repeat that in general
globals are a bad idea. To provide a couple of reasons:
They provide non-obvious coupling between functions
The prevent you from reusing the function on a different piece of data

I'm not saying they should *never* be used, but something like a count
of messages does not sound to me like an appropriate use. After all, one
day you might want to have two sets of messages each with it;s own
num_messages.

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....

No, under VMS 1 means success. The *only* portable values are those
quoted above, 0, EXIT_SUCCESS and EXIT_FAILURE. So if your program is
going to produce only one failure code you should use EXIT_FAILURE.

There are valid reasons for using non-portable return values (for
example when you need to flag different kinds of failure), but in that
case you should not use magic numbers but either enums of #defines so
that they can easily be changed when porting to other systems.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Keith Thompson]

"Mike Wahler" <mk******@mkwah ler.net> writes:

"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).

And just to make it clear that this is more than just theoretical, VMS
(now called OpenVMS) defines any odd number as a successful status,
and any even number as a failure indication. The C implementation
translates exit(0) to return a status of 1, but it doesn't translate
any other values. So a program that does exit(0), exit(EXIT_SUCCE SS),
or exit(EXIT_FAILU RE) will behave as expected, but exit(1) will
indicate that the program succeeded. (I think EXIT_FAILURE may be
defined as 2, but I wouldn't bet on it.)

The fact that EXIT_SUCCESS isn't necessarily 0 may be just
theoretical, though; I've never heard of an implementation with
EXIT_SUCCESS != 0.

In some ways, it might have been clearer for the C standard only to
define the behavior of EXIT_SUCCESS and EXIT_FAILURE, leaving 0
implementation-defined.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <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.

[Martin Ambuhl]

ncf wrote:

Flash Gordon wrote:

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....

EXIT_FAILURE has a standardly defined meaning as an argument to exit(),
as do 0 and EXIT_SUCCESS. On the other hand, 1 as an argument to exit()
does not have a standardly defined meaning, and it damn sure doesn't
mean "generic error in the first place."

[ncf]

> >>> My, you _really_ have promise ;-)

s/have/show/

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)

You not only took the advice and followed it but also
thanked the one giving it...

Heh, thankee. I'd much rather say thank you than to not say it and
leave my appreciation unknown. :)

Have a GREAT day :)
-Wes

[Joe Wright]

Martin Ambuhl wrote:

ncf wrote:

Flash Gordon wrote:

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....

EXIT_FAILURE has a standardly defined meaning as an argument to exit(),
as do 0 and EXIT_SUCCESS. On the other hand, 1 as an argument to exit()
does not have a standardly defined meaning, and it damn sure doesn't
mean "generic error in the first place."

Has it been noted recently that an arbitrary C program is often a
function called by the Unix shell in a program of its own?

By convention the shell, if it cares, will check the return value of the
function. Again, by convention, integer 0 indicates success and other
values indicate other things.

In any case, the return value of a C program is defined in the contract
between the C program and the shell program that called it. In other
words Implementation Specific.

Unhappily, the C Standard divorces itself from the Unix shell and does
not elaborate on the possible return values of a C programm beyond
EXIT_SUCCESS, 0 and EXIT_FAILURE.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Niklas Norrthon]

Flash Gordon <sp**@flash-gordon.me.uk> writes:

Niklas Norrthon wrote:

"ncf" <no************ ***@gmail.com> writes:

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.

You are right of course. Personally I am usually too lazy to type it out,
so I use the zero for indicating success. Perhaps thats why my mind slipped.

Furthermore I'd say it's perfectly acceptable to use other return than
these, when coding for a specific platform where such return codes
make sense, and can carry additional information to the calling program,
(as long as one does not post such code in this forum)

/Niklas Norrthon