free() is useless...

[Emmanuel Delahaye]

William L. Bahn wrote on 02/09/04 :

Unless your compiler, like mine, would throw the following error
(not warning):

Compiling JUNKER.C:
Error JUNKER.C 19: Cannot convert 'void *' to 'char *' in
function main()

And that's when it is configured for ANSI compliance

Sounds to be a C++ compiler. (g++, I presume)

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

 

[Emmanuel Delahaye]

William L. Bahn wrote on 03/09/04 :

But are they the same?

yes, no, may be. Implementation issue.

I know what value "return 0;" will return. What value will
"return EXIT_SUCCESS;" return?

A value meaning succes. Not necesseraly 0.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

 

[Emmanuel Delahaye]

William L. Bahn wrote on 03/09/04 :

Agreed. But when I use EXIT_SUCCESS, I don't know if that will
return a 0 or not.

Who cares?

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

 

[Keith Thompson]

William L. Bahn wrote on 03/09/04 :

Who cares?

Well, I do.

On the systems I use, 0 happens to be the only program exit status
that indicates success, so I can be reasonably sure that "return 0;"
and "return EXIT_SUCCESS;" will have exactly the same effect. But on
another system with multiple ways to indicate success, there might be
a real visible difference.

(In fact, I suspect that all existing systems simply define
EXIT_SUCCESS as 0, though EXIT_FAILURE can vary.)

 

[Mark McIntyre]

Well, I do.

Hmm? Remember that the return value of main is NOT what is returned to the
OS. The value returned from main merely informs the stub loader to return a
status of "successful termination" to the OS. Therefore EXIT_SUCCESS could
be defined as 42 for all you care?

On the systems I use, 0 happens to be the only program exit status
that indicates success, so I can be reasonably sure that "return 0;"
and "return EXIT_SUCCESS;" will have exactly the same effect. But on
another system with multiple ways to indicate success, there might be
a real visible difference.

I don't believe thats allowed is it? Putting 5.1.2.2.3 with 7.20.4.3 seems
to imply that EXIT_SUCCESS and 0 must result in the same effect.

 

[Keith Thompson]

Hmm? Remember that the return value of main is NOT what is returned to the
OS. The value returned from main merely informs the stub loader to return a
status of "successful termination" to the OS. Therefore EXIT_SUCCESS could
be defined as 42 for all you care?

Certainly, and I don't care about the distinction (if any) if I'm
trying to write strictly portable code. The question is whether
"return 0;" and "return EXIT_SUCCESS;" have the same effect. I think
the standard is ambiguous.

I don't believe thats allowed is it? Putting 5.1.2.2.3 with 7.20.4.3 seems
to imply that EXIT_SUCCESS and 0 must result in the same effect.

C99 7.20.4.3p5 says:

If the value of status is zero or EXIT_SUCCESS, an
implementation-defined form of the status successful termination
is returned.

One way to interpret this is that both zero and EXIT_SUCCESS must
return the *same* form of successful termination, but I think it can
also be consistently read as equivalent to the following:

If the value of status is zero, an implementation-defined form of
the status successful termination is returned. If the value of
status is EXIT_SUCCESS, an implementation-defined form of the
status successful termination is returned.

Note that if the authors of the standard had intended to require
exit(0) and exit(EXIT_SUCCESS) to have exactly the same effect, they
could have required EXIT_SUCCESS to be defined as 0.

The Rationale doesn't clear this up; it just says, "EXIT_SUCCESS was
added as well."

Of course an implementer can avoid worrying about the ambiguity by
defining EXIT_SUCCESS as 0.

 

[tristan]

/* the size of a pointer variable! */
size = sizeof("foobar");

Not so. The type of a string literal is char[], and sizeof returns the
size in bytes of an array given as its operand.

No, there's a specific exception for sizeof.

C99 6.3.2.1p3:

Except when it is the operand of the sizeof operator or the unary
& operator, or is a string literal used to initialize an array, an
expression that has type "array of type" is converted to an
expression with type "pointer to type" that points to the initial
element of the array object and is not an lvalue.

sizeof("foobar") yields 7.

This came as a surprise, but a few moments of reflection convinced me
that it's more intuitive for it to be so. Thinking of string literals
as recursively named arrays defined inline actually makes them less of
a special-case entity than I had previously thought they were

In fact, I actually sort of knew that they're arrays (the contents must
obviously exist somewhere), but I'd believed that they were always of
pointer type as far as their actual use was concerned. In my defense,
K&R2 says so pretty explicitly: "That is, a string constant is accessed
by a pointer to its first element." (p.104, sec 5.5) although looking
at it now, I can see that the statement was meant to be taken only in
reference to their example, which passes a literal to a function, rather
than in a broader context. However, it's not particularly clear that's
what was intended when one doesn't already know.

In any case, I now know why everyone else had failed to notice the
"obvious error"