malloc trouble

[Michael Mair]

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)

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

-Michael

 

[Michael Mair]

s/have/show/


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

-Michael

 

[Flash Gordon]

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.

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.

 

[Keith Thompson]

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_SUCCESS),
or exit(EXIT_FAILURE) 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.

 

[Martin Ambuhl]

Flash Gordon wrote:

0, EXIT_OK, and EXIT_FAILURE */

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/

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]

0, EXIT_OK, and EXIT_FAILURE */



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.

 

[Niklas Norrthon]

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