free(); after return();?

[Robert]

Alright, here's my situation:

if i use malloc like:

char *mystring;

mystring = (char *)malloc(80);

return mystring;
free(mystring);

is the memory of mystring then freed or does this creates
memory leaks? And if so, how could i prevent this?

Thanks in advance,
Robert

[fb]

ipo wrote:
<snip top-posted crap>

Finally, whoever told you that void main(void) is not valid C? I recommend
you get a copy of K&R and read it.
ipo

I'm very sure he has. Have you? Also I think the latest C standard
would help you out.

I can't believe ignorance such as yours exists in this world.

Loser.

[Greg P.]

"Robert" <R.****@hetnet.nl> wrote in message
news:bj**********@reader11.wxs.nl...
| is the memory of mystring then freed or does this creates
| memory leaks? And if so, how could i prevent this?
it sure does, as free is not reached.

Outside of your function call free() on it once you are done with it. It
doesn't have to be in the same scope.

[ipo]

The memory of mystring is not freed by this code since the function returns
prior to reaching free(mystring). Whether you will run into memory leaks
depends on whether the memory is freed elsewhere in the program. Don't
confuse the scope of the local variable mystring with the scope of the thing
it points to. Your code should read as follows:

char *getString(void) {
char *mystring;

mystring = (char *) malloc(80* sizeof(char));
return(mystring);
}

void main(void) {
char *myName;

myName = getString();

if (myName != NULL) {
strcpy(myName, "Bill Clinton");
printf("%s\n", myName);
free(myName);
}
}

When getString() returns, mystring goes out of scope. But note that what the
function returns is a pointer to a 80-character memory chunk. After that
note that I make sure that main() calls free() to release the memory chunk
once I'm done with it.

I hope this helps
ipo

"Robert" <R.****@hetnet.nl> wrote in message
news:bj**********@reader11.wxs.nl...

Alright, here's my situation:

if i use malloc like:

char *mystring;

mystring = (char *)malloc(80);

return mystring;
free(mystring);

is the memory of mystring then freed or does this creates
memory leaks? And if so, how could i prevent this?

Thanks in advance,
Robert

[Jarno A Wuolijoki]

On Sat, 6 Sep 2003, ipo wrote:

2. By definition sizeof(char) maybe 1 in your machine. Not mine. So make
sure to use sizeof(char) to be portable.

Since sizeof returns the size of an object in units of char don't you
think you should multiply it with another sizeof(char)?

[Jack Klein]

On Sat, 06 Sep 2003 02:43:52 GMT, "ipo" <ip********@netscape.net>
wrote in comp.lang.c:

****DON'T TOP POST. New material you add belongs after quoted
material you are referring to. If you want to use Microsoft's
brain-dead virus spreading and posting software (free, and not worth
its price), then YOU need to make the extra effort to put the cursor
where it belongs before you start typing.

The memory of mystring is not freed by this code since the function returns
prior to reaching free(mystring). Whether you will run into memory leaks
depends on whether the memory is freed elsewhere in the program. Don't
confuse the scope of the local variable mystring with the scope of the thing
it points to. Your code should read as follows:
NO IT SHOULD NOT READ AS FOLLOWS. Your example contains examples of
both poor C programming practice and undefined behavior.
char *getString(void) {
char *mystring;

mystring = (char *) malloc(80* sizeof(char));
Poor practices:

1. NEVER cast the pointer returned by malloc() in C. It is not
necessary if <stdlib.h> has been included, and can hide a valuable
warning if <stdlib.h> has not been included.

2. By definition, sizeof(char) in C is 1. It always has been, and
always will be. Multiplying by sizeof(char) is always unnecessary and
obfuscating.

Instead code the line above:

mystring = malloc(80 * sizeof *mystring);

Now the code is bullet-proof, even if you change the type of mystring
to be a pointer to something else larger than 1 byte.

And now your compiler is required to issue a diagnostic if you did not
include <stdlib.h> or otherwise have a valid prototype for malloc() in
scope, saving you from potential undefined behavior at run time.
return(mystring);
}

void main(void) {
Apparently you are talking about some language other than C, no matter
how much it looks like C. I understand that "void main()" is correct
Java, for example, but it is not legal C. main() returns an int in C.
char *myName;

myName = getString();

if (myName != NULL) {
strcpy(myName, "Bill Clinton");
printf("%s\n", myName);
free(myName);
}
}

When getString() returns, mystring goes out of scope. But note that what the
function returns is a pointer to a 80-character memory chunk. After that
note that I make sure that main() calls free() to release the memory chunk
once I'm done with it.

I hope this helps
ipo

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

[Allan Bruce]

"ipo" <ip********@netscape.net> wrote in message
news:7Y********************@news04.bloor.is.net.ca ble.rogers.com...

FYI:

1. malloc() returns a void pointer and there is absolutely nothing wrong
with using a type cast on the return value. In case you did not know,
stdlib.h has nothing to do with casting. Whether you decide to cast or not
any decent compiler will generate a warning and assume a return value of int for malloc() if stdlib.h is not included.
Imagine you had the following
int *myNum
char *myString

myNum = (char *)malloc(80 * sizeof(char));

Then this is surely not what you want, but no error will be raised.

2. By definition sizeof(char) maybe 1 in your machine. Not mine. So make
sure to use sizeof(char) to be portable.

You have a very strange machine indeed. The standard defines the size of a
char is 1 Byte, however a byte doesnt have to be 8 bits.

Allan

[Martin Ambuhl]

ipo wrote:

[...]

Whether you decide to cast or not
any decent compiler will generate a warning and assume a return value of int
for malloc() if stdlib.h is not included.
Troll alert #1
2. By definition sizeof(char) maybe 1 in your machine. Not mine. So make
sure to use sizeof(char) to be portable.
Troll alert #2
Finally, whoever told you that void main(void) is not valid C? I recommend
you get a copy of K&R and read it.

Troll alert #3

Reserving plonk until I see if the humor gets any better.

--
Martin Ambuhl

[ipo]

FYI:

1. malloc() returns a void pointer and there is absolutely nothing wrong
with using a type cast on the return value. In case you did not know,
stdlib.h has nothing to do with casting. Whether you decide to cast or not
any decent compiler will generate a warning and assume a return value of int
for malloc() if stdlib.h is not included.

2. By definition sizeof(char) maybe 1 in your machine. Not mine. So make
sure to use sizeof(char) to be portable.

Finally, whoever told you that void main(void) is not valid C? I recommend
you get a copy of K&R and read it.
ipo

"Jack Klein" <ja*******@spamcop.net> wrote in message
news:eo********************************@4ax.com... > On Sat, 06 Sep 2003
02:43:52 GMT, "ipo" <ip********@netscape.net>

wrote in comp.lang.c:

****DON'T TOP POST. New material you add belongs after quoted
material you are referring to. If you want to use Microsoft's
brain-dead virus spreading and posting software (free, and not worth
its price), then YOU need to make the extra effort to put the cursor
where it belongs before you start typing.

The memory of mystring is not freed by this code since the function returns prior to reaching free(mystring). Whether you will run into memory leaks
depends on whether the memory is freed elsewhere in the program. Don't
confuse the scope of the local variable mystring with the scope of the thing it points to. Your code should read as follows:

NO IT SHOULD NOT READ AS FOLLOWS. Your example contains examples of
both poor C programming practice and undefined behavior.

char *getString(void) {
char *mystring;

mystring = (char *) malloc(80* sizeof(char));

Poor practices:

1. NEVER cast the pointer returned by malloc() in C. It is not
necessary if <stdlib.h> has been included, and can hide a valuable
warning if <stdlib.h> has not been included.

2. By definition, sizeof(char) in C is 1. It always has been, and
always will be. Multiplying by sizeof(char) is always unnecessary and
obfuscating.

Instead code the line above:

mystring = malloc(80 * sizeof *mystring);

Now the code is bullet-proof, even if you change the type of mystring
to be a pointer to something else larger than 1 byte.

And now your compiler is required to issue a diagnostic if you did not
include <stdlib.h> or otherwise have a valid prototype for malloc() in
scope, saving you from potential undefined behavior at run time.

return(mystring);
}

void main(void) {

Apparently you are talking about some language other than C, no matter
how much it looks like C. I understand that "void main()" is correct
Java, for example, but it is not legal C. main() returns an int in C.

char *myName;

myName = getString();

if (myName != NULL) {
strcpy(myName, "Bill Clinton");
printf("%s\n", myName);
free(myName);
}
}

When getString() returns, mystring goes out of scope. But note that what the function returns is a pointer to a 80-character memory chunk. After that
note that I make sure that main() calls free() to release the memory chunk once I'm done with it.

I hope this helps
ipo

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

[fb]

ipo wrote:
<snip top-posted crap>

Finally, whoever told you that void main(void) is not valid C? I recommend
you get a copy of K&R and read it.
ipo

I'm very sure he has. Have you? Also I think the latest C standard
would help you out.

I can't believe ignorance such as yours exists in this world.

Loser.

[Irrwahn Grausewitz]

richard <[e-mail]> wrote:

On Sat, 06 Sep 2003 04:05:45 GMT, Jack Klein <ja*******@spamcop.net> wrote:

mystring = malloc(80 * sizeof *mystring);

Style question - why (80 * sizeof *mystring) rather than
(80 * sizeof(*mystring)) ?

It has a positive impact on code readability:

sizeof xyz

suggests that xyz is an /object/, whereas:

sizeof (abc)

suggests that abc is a /type/, as the construct:

sizeof (type)

is the only one where the parantheses are required.

Furthermore: note the blank between "sizeof" and "(...)" :
sizeof is an operator, not a function.

Irrwahn
--
What does this red button do?

[Richard Delorme]

richard a écrit :

On Sat, 06 Sep 2003 04:05:45 GMT, Jack Klein <ja*******@spamcop.net>
wrote:

mystring = malloc(80 * sizeof *mystring);

Style question - why (80 * sizeof *mystring) rather than
(80 * sizeof(*mystring)) ?

sizeof is an operator and not a function. IMHO, avoiding the parentheses
makes the nature of sizeof clearer.

--
Richard

[Richard Heathfield]

richard wrote:

On Sat, 06 Sep 2003 04:05:45 GMT, Jack Klein <ja*******@spamcop.net>
wrote:

mystring = malloc(80 * sizeof *mystring);

Style question - why (80 * sizeof *mystring) rather than
(80 * sizeof(*mystring)) ?

Style question - why (80 * sizeof(*mystring)) rather than
((((((80))))) * (((((sizeof((((*(((mystring)))))))))))) ?
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Jarno A Wuolijoki]

On Sat, 6 Sep 2003, ipo wrote:

2. By definition sizeof(char) maybe 1 in your machine. Not mine. So make
sure to use sizeof(char) to be portable.

Since sizeof returns the size of an object in units of char don't you
think you should multiply it with another sizeof(char)?

[Allan Bruce]

"ipo" <ip********@netscape.net> wrote in message
news:7Y********************@news04.bloor.is.net.ca ble.rogers.com...

FYI:

1. malloc() returns a void pointer and there is absolutely nothing wrong
with using a type cast on the return value. In case you did not know,
stdlib.h has nothing to do with casting. Whether you decide to cast or not
any decent compiler will generate a warning and assume a return value of int for malloc() if stdlib.h is not included.
Imagine you had the following
int *myNum
char *myString

myNum = (char *)malloc(80 * sizeof(char));

Then this is surely not what you want, but no error will be raised.

2. By definition sizeof(char) maybe 1 in your machine. Not mine. So make
sure to use sizeof(char) to be portable.

You have a very strange machine indeed. The standard defines the size of a
char is 1 Byte, however a byte doesnt have to be 8 bits.

Allan

[Martin Ambuhl]

ipo wrote:

[...]

Whether you decide to cast or not
any decent compiler will generate a warning and assume a return value of int
for malloc() if stdlib.h is not included.
Troll alert #1
2. By definition sizeof(char) maybe 1 in your machine. Not mine. So make
sure to use sizeof(char) to be portable.
Troll alert #2
Finally, whoever told you that void main(void) is not valid C? I recommend
you get a copy of K&R and read it.

Troll alert #3

Reserving plonk until I see if the humor gets any better.

--
Martin Ambuhl

[Peter Nilsson]

"Irrwahn Grausewitz" <ir*****@freenet.de> wrote in message
news:98********************************@4ax.com...
....

Furthermore: note the blank between "sizeof" and "(...)" :
What of it?
sizeof is an operator, not a function.

Some people's style is to code with spaces between the function name and the
parenthesised argument list. It's not my preference, but there's nothing
syntactically wrong with it.

--
Peter

[Peter Nilsson]

"Allan Bruce" <al*****@TAKEAWAYf2s.com> wrote in message
news:bj**********@news.freedom2surf.net...
....

Imagine you had the following
int *myNum
char *myString

myNum = (char *)malloc(80 * sizeof(char));

Then this is surely not what you want, but no error will be raised.

Missing semicolons aside, this does require a diagnostic.

You appear to be arguing the case *for* malloc casting. ;)

--
Peter

[Allin Cottrell]

richard wrote:

Style question - why (80 * sizeof *mystring) rather than
(80 * sizeof(*mystring)) ?

Style question - why (80 * sizeof(*mystring)) rather than
((((((80))))) * (((((sizeof((((*(((mystring)))))))))))) ?

because there are no cases in c in which ((whatever)) adds anything to
(whatever). There are cases in which (whatever) is better than whatever.

True, but in this case the absence of parentheses is a marker of
a good understanding of what's going on -- namely that "sizeof"
is not a function, and does not require parentheses if its
operand is an object (rather than a type). Compare

double *x;

/* below: not recommended, but the parentheses are needed */
x = malloc(10 * sizeof(double));

/* recommended, and parentheses would be redundant */
x = malloc(10 * sizeof *x);

--
Allin Cottrell
Department of Economics
Wake Forest University, NC

[ipo]

"Allan Bruce" <al*****@TAKEAWAYf2s.com> wrote in message
news:bj**********@news.freedom2surf.net...

"ipo" <ip********@netscape.net> wrote in message
news:7Y********************@news04.bloor.is.net.ca ble.rogers.com...

FYI:

1. malloc() returns a void pointer and there is absolutely nothing wrong
with using a type cast on the return value. In case you did not know,
stdlib.h has nothing to do with casting. Whether you decide to cast or not any decent compiler will generate a warning and assume a return value of int

for malloc() if stdlib.h is not included.

Imagine you had the following
int *myNum
char *myString

myNum = (char *)malloc(80 * sizeof(char));

Do you test your code before posting it? It seems not. Not only the compiler
will give you an error about incompatible types but it will also complain
about the missing semicolons.
Then this is surely not what you want, but no error will be raised.

2. By definition sizeof(char) maybe 1 in your machine. Not mine. So make
sure to use sizeof(char) to be portable.
You have a very strange machine indeed. The standard defines the size of

a char is 1 Byte, however a byte doesnt have to be 8 bits.

Allan

[Richard Heathfield]

richard wrote:

On Sat, 6 Sep 2003 13:38:55 +0000 (UTC), Richard Heathfield
<do******@address.co.uk.invalid> wrote:

richard wrote:

On Sat, 06 Sep 2003 04:05:45 GMT, Jack Klein <ja*******@spamcop.net>
wrote:

mystring = malloc(80 * sizeof *mystring);

Style question - why (80 * sizeof *mystring) rather than
(80 * sizeof(*mystring)) ?

Style question - why (80 * sizeof(*mystring)) rather than
((((((80))))) * (((((sizeof((((*(((mystring)))))))))))) ?

because there are no cases in c in which ((whatever)) adds anything to
(whatever). There are cases in which (whatever) is better than whatever.

It is true that such cases exist - for example, to resolve apparent
precedence ambiguities (for the maintainer, of course, not for the
compiler, which we can assume will get the precedence correct without the
parentheses).

But what specific advantage does enclosing *mystring in parentheses add?

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Irrwahn Grausewitz]

richard <[e-mail]> wrote:

On Sat, 06 Sep 2003 04:05:45 GMT, Jack Klein <ja*******@spamcop.net> wrote:

mystring = malloc(80 * sizeof *mystring);

Style question - why (80 * sizeof *mystring) rather than
(80 * sizeof(*mystring)) ?

It has a positive impact on code readability:

sizeof xyz

suggests that xyz is an /object/, whereas:

sizeof (abc)

suggests that abc is a /type/, as the construct:

sizeof (type)

is the only one where the parantheses are required.

Furthermore: note the blank between "sizeof" and "(...)" :
sizeof is an operator, not a function.

Irrwahn
--
What does this red button do?

[Richard Heathfield]

ipo wrote:

FYI:

1. malloc() returns a void pointer and there is absolutely nothing wrong
with using a type cast on the return value.
Wrong. There is plenty wrong with it. All code should either do something
good or stop something bad happening. A malloc cast does neither. What it
/can/ do, however, is prevent you from being told that something bad has
happened. Therefore, it confers no advantage and yet suffers from a
possible disadvantage. Therefore, there is no good reason to include it.
In case you did not know,
stdlib.h has nothing to do with casting.
Jack knows that full well. Your inability to understand his point does not
constitute a failure of understanding on his part.
Whether you decide to cast or not
any decent compiler will generate a warning and assume a return value of
int for malloc() if stdlib.h is not included.
Wrong. If the cast is omitted without <stdlib.h> being included, the
compiler /must/ diagnose. If the cast is included, the diagnostic becomes
optional.

2. By definition sizeof(char) maybe 1 in your machine. Not mine. So make
sure to use sizeof(char) to be portable.
Wrong. The ISO C standard requires sizeof(char) to evaluate to 1 in all
cases.

Finally, whoever told you that void main(void) is not valid C?
Whoever told you it was?
I recommend
you get a copy of K&R and read it.

Feel free to provide a page reference to a void main(void) program in K&R.
You won't find one, but the read might do you some good.
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Richard Delorme]

richard a écrit :

On Sat, 06 Sep 2003 04:05:45 GMT, Jack Klein <ja*******@spamcop.net>
wrote:

mystring = malloc(80 * sizeof *mystring);

Style question - why (80 * sizeof *mystring) rather than
(80 * sizeof(*mystring)) ?

sizeof is an operator and not a function. IMHO, avoiding the parentheses
makes the nature of sizeof clearer.

--
Richard

[Irrwahn Grausewitz]

"Peter Nilsson" <ai***@acay.com.au> wrote:

"Irrwahn Grausewitz" <ir*****@freenet.de> wrote in message
news:98********************************@4ax.com.. .
...

Furthermore: note the blank between "sizeof" and "(...)" :
What of it?

There's only one between the operator and the paranthesized expression.

sizeof is an operator, not a function.

Some people's style is to code with spaces between the function name and the
parenthesised argument list. It's not my preference, but there's nothing
syntactically wrong with it.

Nobody said so.
--
What does this red button do?

[Richard Heathfield]

richard wrote:

On Sat, 06 Sep 2003 04:05:45 GMT, Jack Klein <ja*******@spamcop.net>
wrote:

mystring = malloc(80 * sizeof *mystring);

Style question - why (80 * sizeof *mystring) rather than
(80 * sizeof(*mystring)) ?

Style question - why (80 * sizeof(*mystring)) rather than
((((((80))))) * (((((sizeof((((*(((mystring)))))))))))) ?
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Peter Nilsson]

"Irrwahn Grausewitz" <ir*****@freenet.de> wrote in message
news:98********************************@4ax.com...
....

Furthermore: note the blank between "sizeof" and "(...)" :
What of it?
sizeof is an operator, not a function.

Some people's style is to code with spaces between the function name and the
parenthesised argument list. It's not my preference, but there's nothing
syntactically wrong with it.

--
Peter

[Peter Nilsson]

"Irrwahn Grausewitz" <ir*****@freenet.de> wrote in message
news:ue********************************@4ax.com...

"Peter Nilsson" <ai***@acay.com.au> wrote:

"Irrwahn Grausewitz" <ir*****@freenet.de> wrote in message
news:98********************************@4ax.com.. .
...

Furthermore: note the blank between "sizeof" and "(...)" :

What of it?

There's only one between the operator and the paranthesized expression.

Umm... why is that important?

Two spaces would look stupid I grant you.

sizeof is an operator, not a function.

Some people's style is to code with spaces between the function name and theparenthesised argument list. It's not my preference, but there's nothing
syntactically wrong with it.

Nobody said so.

AFAIK, no one said sizeof was a function either, so I wasn't sure why you
mentioned it. Seeing your two statements together, separated by a colon, I
thought your first comment was somehow meant to imply the second.

Are you simply saying that sizeof should always be followed by a space in
light of its status as an operator? If so, you wouldn't be the only one, but
I don't see it as being particularly crucial to writing readable or robust
code [in the circumstance where the operand is a type or parethesised
expression]. YMMV.

--
Peter

[Peter Nilsson]

"Allan Bruce" <al*****@TAKEAWAYf2s.com> wrote in message
news:bj**********@news.freedom2surf.net...
....

Imagine you had the following
int *myNum
char *myString

myNum = (char *)malloc(80 * sizeof(char));

Then this is surely not what you want, but no error will be raised.

Missing semicolons aside, this does require a diagnostic.

You appear to be arguing the case *for* malloc casting. ;)

--
Peter

[Allin Cottrell]

richard wrote:

Style question - why (80 * sizeof *mystring) rather than
(80 * sizeof(*mystring)) ?

Style question - why (80 * sizeof(*mystring)) rather than
((((((80))))) * (((((sizeof((((*(((mystring)))))))))))) ?

because there are no cases in c in which ((whatever)) adds anything to
(whatever). There are cases in which (whatever) is better than whatever.

True, but in this case the absence of parentheses is a marker of
a good understanding of what's going on -- namely that "sizeof"
is not a function, and does not require parentheses if its
operand is an object (rather than a type). Compare

double *x;

/* below: not recommended, but the parentheses are needed */
x = malloc(10 * sizeof(double));

/* recommended, and parentheses would be redundant */
x = malloc(10 * sizeof *x);

--
Allin Cottrell
Department of Economics
Wake Forest University, NC

[ipo]

"Allan Bruce" <al*****@TAKEAWAYf2s.com> wrote in message
news:bj**********@news.freedom2surf.net...

"ipo" <ip********@netscape.net> wrote in message
news:7Y********************@news04.bloor.is.net.ca ble.rogers.com...

FYI:

1. malloc() returns a void pointer and there is absolutely nothing wrong
with using a type cast on the return value. In case you did not know,
stdlib.h has nothing to do with casting. Whether you decide to cast or not any decent compiler will generate a warning and assume a return value of int

for malloc() if stdlib.h is not included.

Imagine you had the following
int *myNum
char *myString

myNum = (char *)malloc(80 * sizeof(char));

Do you test your code before posting it? It seems not. Not only the compiler
will give you an error about incompatible types but it will also complain
about the missing semicolons.
Then this is surely not what you want, but no error will be raised.

2. By definition sizeof(char) maybe 1 in your machine. Not mine. So make
sure to use sizeof(char) to be portable.
You have a very strange machine indeed. The standard defines the size of

a char is 1 Byte, however a byte doesnt have to be 8 bits.

Allan

[Richard Heathfield]

richard wrote:

On Sat, 6 Sep 2003 13:38:55 +0000 (UTC), Richard Heathfield
<do******@address.co.uk.invalid> wrote:

richard wrote:

On Sat, 06 Sep 2003 04:05:45 GMT, Jack Klein <ja*******@spamcop.net>
wrote:

mystring = malloc(80 * sizeof *mystring);

Style question - why (80 * sizeof *mystring) rather than
(80 * sizeof(*mystring)) ?

Style question - why (80 * sizeof(*mystring)) rather than
((((((80))))) * (((((sizeof((((*(((mystring)))))))))))) ?

because there are no cases in c in which ((whatever)) adds anything to
(whatever). There are cases in which (whatever) is better than whatever.

It is true that such cases exist - for example, to resolve apparent
precedence ambiguities (for the maintainer, of course, not for the
compiler, which we can assume will get the precedence correct without the
parentheses).

But what specific advantage does enclosing *mystring in parentheses add?

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Richard Heathfield]

ipo wrote:

FYI:

1. malloc() returns a void pointer and there is absolutely nothing wrong
with using a type cast on the return value.
Wrong. There is plenty wrong with it. All code should either do something
good or stop something bad happening. A malloc cast does neither. What it
/can/ do, however, is prevent you from being told that something bad has
happened. Therefore, it confers no advantage and yet suffers from a
possible disadvantage. Therefore, there is no good reason to include it.
In case you did not know,
stdlib.h has nothing to do with casting.
Jack knows that full well. Your inability to understand his point does not
constitute a failure of understanding on his part.
Whether you decide to cast or not
any decent compiler will generate a warning and assume a return value of
int for malloc() if stdlib.h is not included.
Wrong. If the cast is omitted without <stdlib.h> being included, the
compiler /must/ diagnose. If the cast is included, the diagnostic becomes
optional.

2. By definition sizeof(char) maybe 1 in your machine. Not mine. So make
sure to use sizeof(char) to be portable.
Wrong. The ISO C standard requires sizeof(char) to evaluate to 1 in all
cases.

Finally, whoever told you that void main(void) is not valid C?
Whoever told you it was?
I recommend
you get a copy of K&R and read it.

Feel free to provide a page reference to a void main(void) program in K&R.
You won't find one, but the read might do you some good.
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Irrwahn Grausewitz]

"Peter Nilsson" <ai***@acay.com.au> wrote:

"Irrwahn Grausewitz" <ir*****@freenet.de> wrote in message
news:98********************************@4ax.com.. .
...

Furthermore: note the blank between "sizeof" and "(...)" :
What of it?

There's only one between the operator and the paranthesized expression.

sizeof is an operator, not a function.

Some people's style is to code with spaces between the function name and the
parenthesised argument list. It's not my preference, but there's nothing
syntactically wrong with it.

Nobody said so.
--
What does this red button do?

[Peter Nilsson]

"Irrwahn Grausewitz" <ir*****@freenet.de> wrote in message
news:ue********************************@4ax.com...

"Peter Nilsson" <ai***@acay.com.au> wrote:

"Irrwahn Grausewitz" <ir*****@freenet.de> wrote in message
news:98********************************@4ax.com.. .
...

Furthermore: note the blank between "sizeof" and "(...)" :

What of it?

There's only one between the operator and the paranthesized expression.

Umm... why is that important?

Two spaces would look stupid I grant you.

sizeof is an operator, not a function.

Some people's style is to code with spaces between the function name and theparenthesised argument list. It's not my preference, but there's nothing
syntactically wrong with it.

Nobody said so.

AFAIK, no one said sizeof was a function either, so I wasn't sure why you
mentioned it. Seeing your two statements together, separated by a colon, I
thought your first comment was somehow meant to imply the second.

Are you simply saying that sizeof should always be followed by a space in
light of its status as an operator? If so, you wouldn't be the only one, but
I don't see it as being particularly crucial to writing readable or robust
code [in the circumstance where the operand is a type or parethesised
expression]. YMMV.

--
Peter

[Ben Pfaff]

"ipo" <ip********@netscape.net> writes:

1. malloc() returns a void pointer and there is absolutely nothing wrong
with using a type cast on the return value. In case you did not know,
stdlib.h has nothing to do with casting. Whether you decide to cast or not
any decent compiler will generate a warning and assume a return value of int
for malloc() if stdlib.h is not included.

2. By definition sizeof(char) maybe 1 in your machine. Not mine. So make
sure to use sizeof(char) to be portable.

Finally, whoever told you that void main(void) is not valid C? I recommend
you get a copy of K&R and read it.

\|||/
(o o)
|~~~~ooO~~(_)~~~~~~~|
| Please |
| don't feed the |
| TROLLS ! |
'~~~~~~~~~~~~~~Ooo~~'
|__|__|
|| ||
ooO Ooo

--
Just another C hacker.

[ipo]

"Richard Heathfield" <do******@address.co.uk.invalid> wrote in message
news:bj**********@titan.btinternet.com...

ipo wrote:

FYI:

1. malloc() returns a void pointer and there is absolutely nothing wrong
with using a type cast on the return value.
Wrong. There is plenty wrong with it. All code should either do something
good or stop something bad happening. A malloc cast does neither. What it
/can/ do, however, is prevent you from being told that something bad has
happened. Therefore, it confers no advantage and yet suffers from a
possible disadvantage. Therefore, there is no good reason to include it.

If my memory does not fail me, prior to the ANSI C days, malloc() was
declared as char *malloc(). Having said this, please refer to K&R[78]
p.133-134 where the authors use char *alloc(). For additional comments and
examples please refer to the following:

1. The C++ Programming language. Bjarne Stroustrup, p.52-53
2. Checking C Programs with lint. Ian Darwin, p.8-9
3. MDSN documentation on malloc()

In case you did not know,
stdlib.h has nothing to do with casting.

Jack knows that full well. Your inability to understand his point does not
constitute a failure of understanding on his part.

I understood his point very well but please let me remind you that he
started the flames...

Whether you decide to cast or not
any decent compiler will generate a warning and assume a return value of
int for malloc() if stdlib.h is not included.

Wrong. If the cast is omitted without <stdlib.h> being included, the
compiler /must/ diagnose. If the cast is included, the diagnostic becomes
optional.

If the cast is omitted and <stdlib.h> is not included the compiler: 1) will
assume that malloc() returns int, 2) provide you with a warning to that
effect, and 3) warn you about mixing char * and int. If the cast is
specified and <stdlib.h> is not included the compiler, if not lint, will
still warn you about the return type of malloc().

2. By definition sizeof(char) maybe 1 in your machine. Not mine. So make
sure to use sizeof(char) to be portable.
Wrong. The ISO C standard requires sizeof(char) to evaluate to 1 in all
cases.

I'll grant you this one.

Finally, whoever told you that void main(void) is not valid C?

Whoever told you it was?

How about Section 5.1.2.2.1.1 of the ISO C Standard (ISO/IEC 9899:1999)? See
http://homepages.tesco.net/~J.deBoyn...void-main.html

I recommend
you get a copy of K&R and read it.
Feel free to provide a page reference to a void main(void) program in K&R.
You won't find one, but the read might do you some good.

It's true I will not but that does not imply that the construct is not
perfectly legal.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Joona I Palaste]

ipo <ip*@xyz.com> scribbled the following:

"Richard Heathfield" <do******@address.co.uk.invalid> wrote in message
news:bj**********@titan.btinternet.com...

ipo wrote:

> FYI:
>
> 1. malloc() returns a void pointer and there is absolutely nothing wrong
> with using a type cast on the return value.
Wrong. There is plenty wrong with it. All code should either do something
good or stop something bad happening. A malloc cast does neither. What it
/can/ do, however, is prevent you from being told that something bad has
happened. Therefore, it confers no advantage and yet suffers from a
possible disadvantage. Therefore, there is no good reason to include it. If my memory does not fail me, prior to the ANSI C days, malloc() was
declared as char *malloc(). Having said this, please refer to K&R[78]
p.133-134 where the authors use char *alloc(). For additional comments and
examples please refer to the following: 1. The C++ Programming language. Bjarne Stroustrup, p.52-53
2. Checking C Programs with lint. Ian Darwin, p.8-9
3. MDSN documentation on malloc()
So? First of all, we don't live in days prior to ANSI C any more.
Second of all, neither Stroustrup, Darwin, or MS have any authority
over C.

> Finally, whoever told you that void main(void) is not valid C?

Whoever told you it was?

How about Section 5.1.2.2.1.1 of the ISO C Standard (ISO/IEC 9899:1999)? See
http://homepages.tesco.net/~J.deBoyn...void-main.html

I take it that web page reads the C standard like the Devil reads the
Bible. I.e. trying to pick faults wherever it can.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Holy Banana of this, Sacred Coconut of that, Magic Axolotl of the other."
- Guardian in "Jinxter"

[Richard Heathfield]

ipo wrote:

"Richard Heathfield" <do******@address.co.uk.invalid> wrote in message
news:bj**********@titan.btinternet.com...

ipo wrote:

> FYI:
>
> 1. malloc() returns a void pointer and there is absolutely nothing
> wrong with using a type cast on the return value.
Wrong. There is plenty wrong with it. All code should either do something
good or stop something bad happening. A malloc cast does neither. What it
/can/ do, however, is prevent you from being told that something bad has
happened. Therefore, it confers no advantage and yet suffers from a
possible disadvantage. Therefore, there is no good reason to include it.

If my memory does not fail me, prior to the ANSI C days, malloc() was
declared as char *malloc().

Correct. That was around 15 years ago. If you wish to discuss K&R C rather
than ISO C, you should state that explicitly to avoid confusion.
Having said this, please refer to K&R[78]
p.133-134 where the authors use char *alloc(). For additional comments and
examples please refer to the following:

1. The C++ Programming language. Bjarne Stroustrup, p.52-53
Off-topic.
2. Checking C Programs with lint. Ian Darwin, p.8-9
Irrelevant.
3. MDSN documentation on malloc()
Irrelevant.

> In case you did not know,
> stdlib.h has nothing to do with casting.
Jack knows that full well. Your inability to understand his point does
not constitute a failure of understanding on his part.

I understood his point very well but please let me remind you that he
started the flames...

You are confusing flaming with critical analysis.

> Whether you decide to cast or not
> any decent compiler will generate a warning and assume a return value
> of int for malloc() if stdlib.h is not included.
Wrong. If the cast is omitted without <stdlib.h> being included, the
compiler /must/ diagnose. If the cast is included, the diagnostic becomes
optional.

If the cast is omitted and <stdlib.h> is not included the compiler: 1)
will assume that malloc() returns int, 2) provide you with a warning to
that effect, and 3) warn you about mixing char * and int.

Right, and that's why it's important to omit the cast.

If the cast is specified and <stdlib.h> is not included the compiler, if not lint, will
still warn you about the return type of malloc().
It is not required to issue a diagnostic in that circumstance.

<snip>

> Finally, whoever told you that void main(void) is not valid C?

Whoever told you it was?

How about Section 5.1.2.2.1.1 of the ISO C Standard (ISO/IEC 9899:1999)?

That section makes it perfectly clear that any return type other than int
invokes undefined behaviour on any implementation that does not
specifically document some other interface. Thus, void main(void) cannot be
used in code that is intended to be portable.

See

http://homepages.tesco.net/~J.deBoyn...void-main.html

Irrelevant. The Standard defines C.

> I recommend
> you get a copy of K&R and read it.

Feel free to provide a page reference to a void main(void) program in
K&R. You won't find one, but the read might do you some good.

It's true I will not but that does not imply that the construct is not
perfectly legal.

No, it doesn't, but that's irrelevant too. The Standard explicitly says that
main returns int. If you define it to return void, you are at the mercy of
your implementation.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Sheldon Simms]

On Sat, 06 Sep 2003 20:34:09 +0000, Joona I Palaste wrote:

ipo <ip*@xyz.com> scribbled the following:

"Richard Heathfield" <do******@address.co.uk.invalid> wrote in message
news:bj**********@titan.btinternet.com...

ipo wrote:
> Finally, whoever told you that void main(void) is not valid C?

Whoever told you it was?

How about Section 5.1.2.2.1.1 of the ISO C Standard (ISO/IEC 9899:1999)? See
http://homepages.tesco.net/~J.deBoyn...void-main.html

I take it that web page reads the C standard like the Devil reads the
Bible. I.e. trying to pick faults wherever it can.

No, it simply says that it is permissable to define main in some
implementation-defined manner. (i.e. - with a return type of void, as
long as that is explicitly allowed by the implementation).

That is correct, but that only means that void main(void) is valid
in reference to some implementation of C that explicitly allows it.

It doesn't mean anything for implementation-independent validity of
void main(void) independent of implementation.

ipo's argument is approximately the same as saying that

int main (void)
{
_Frubnax w = 0;
return w;
}

is valid C, since "an implementation is allowed to define new keywords
that provide alternative ways to designate a basic (or any other) type"
(6.2.5.14)

[pete]

ipo wrote:

a copy of K&R

If you don't have the errata, then you don't have K&R.

http://cm.bell-labs.com/cm/cs/cbook/2ediffs.html

142(§6.5, toward the end):
The remark about casting the return value of malloc
("the proper method is to declare
.... then explicitly coerce") needs to be rewritten.
The example is correct and works,
but the advice is debatable in the context of the
1988-1989 ANSI/ISO standards. It's not necessary
(given that coercion of void * to ALMOSTANYTYPE * is automatic),
and possibly harmful if malloc, or a proxy for it,
fails to be declared as returning void *.
The explicit cast can cover up an unintended error.
On the other hand, pre-ANSI, the cast was necessary, and it is in C++
also.

--
pete

[pete]

ipo wrote:

2. By definition sizeof(char) maybe 1 in your machine. Not mine.

Try harder.

N869
6.5.3.4 The sizeof operator
[#3] When applied to an operand that has type char, unsigned
char, or signed char, (or a qualified version thereof) the
result is 1.

http://anubis.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/

--
pete

[pete]

ipo wrote:

Finally, whoever told you that void main(void) is not valid C?
I recommend you get a copy of K&R and read it

What page is void main(void) on ?

N869
5.1.2.2.1 Program startup
[#1] The function called at program startup is named main.
The implementation declares no prototype for this function.
It shall be defined with a return type of int and with no
parameters:
int main(void) { /* ... */ }
or with two parameters (referred to here as argc and argv,
though any names may be used, as they are local to the
function in which they are declared):
int main(int argc, char *argv[]) { /* ... */ }
or equivalent; or in some other implementation-defined
manner.

So, void main(void), would be an implementation defined manor.
You said something about sizeof(char),
which indicated that you value portability.
int main(void) is portable, void main(void) isn't.
This newsgroup focuses on portable code,
to the extent that code with void main(void), is Off Topic.

--
pete

[E. Robert Tisdale]

Jack Klein wrote:

NEVER cast the pointer returned by malloc() in C.
It is not necessary if <stdlib.h> has been included
and can hide a valuable warning if <stdlib.h> has not been included.
That's *not* the best advice
if you need to compile your code with a C++ compiler:
cat malloc.c #include <stdlib.h>
#include <stdio.h>

int main(int argc, char* argv[]) {
const
int n = 20;
int* p = malloc(n*sizeof *p);
for (int j = 0; j < n; ++j)
p[j] = j;
for (int j = 0; j < n; ++j)
fprintf(stdout, "%2d = p[%2d]\n", p[j], j);
return 0;
}
g++ -Wall -ansi -pedantic -x C++ -o malloc malloc.c malloc.c: In function `int main(int, char**)':
malloc.c:7: warning: invalid conversion from `void*' to `int*' ./malloc

0 = p[ 0]
1 = p[ 1]

[Richard Heathfield]

E. Robert Tisdale wrote:

Jack Klein wrote:

NEVER cast the pointer returned by malloc() in C.
It is not necessary if <stdlib.h> has been included
and can hide a valuable warning if <stdlib.h> has not been included.
That's *not* the best advice

Yes, it is. I don't seek to persuade Mr Tisdale of this fact, of course.
This reply is merely for the record.
if you need to compile your code with a C++ compiler:

....then write C++ code. This, however, is comp.lang.c, where we discuss C
code, not C++ code. There is a significant difference between C code and
C++ code. That is, C programs generally do not compile under a C++
compiler, and C++ programs generally do not compile under a C compiler.

It is possible to construct programs which compile under both a C compiler
and a C++ compiler, but then it is possible to construct programs which
compile as C, BASIC, and Perl. This is an interesting diversion, but not
appropriate for production code.

In general, use a C compiler for C code, and a C++ compiler for C++ code.
Mixing the two is a recipe for disaster.
If you want C++, you know where to find it.
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[LibraryUser]

"E. Robert Tisdale" wrote:

Jack Klein wrote:

NEVER cast the pointer returned by malloc() in C.
It is not necessary if <stdlib.h> has been included
and can hide a valuable warning if <stdlib.h> has not been included.

That's *not* the best advice
if you need to compile your code with a C++ compiler:

Primus: Closely examine the group name. I fail to see any ++
therein. Intelligent people compile C code with a C compiler.

Secundus: That IS the best advice.

Tertius: If ERT would refrain from posting misinformation, we
could reduce traffic here since the corrections, for the benefit
of the newbies, would no longer be necessary. "Ignore anything
from ERT" is generally good advice.

--
Replies should be to the newsgroup
Replace this line to publish your e-mail address.

[Jack Klein]

On Sat, 06 Sep 2003 06:15:31 GMT, "ipo" <ip********@netscape.net>
wrote in comp.lang.c:

FYI:

1. malloc() returns a void pointer and there is absolutely nothing wrong
with using a type cast on the return value. In case you did not know,
stdlib.h has nothing to do with casting. Whether you decide to cast or not
any decent compiler will generate a warning and assume a return value of int
Every character that a programmer types into a source code file
increases the possibility for a code defect. Redundant casts are
particularly high on that list.

As for your second assertion, a diagnostic is required if you assign
the return value of an unprototyped function to any type of pointer.
No such diagnostic is required in the presence of a cast.

As for "decent", I have seen many compilers that can be configured to
output a diagnostic message for a call to any function without a
prototype in scope. Sadly, many programmers do not configure their
compilers to operate that way. But I have never seen any compiler
that issues a specific warning for this particular scenario, and at
least a few of the compilers I have used over the decades are
"decent".
for malloc() if stdlib.h is not included.

2. By definition sizeof(char) maybe 1 in your machine. Not mine. So make
sure to use sizeof(char) to be portable.
Then you are posting in the wrong newsgroup, because you are not using
a C compiler. I use compilers for architectures where CHAR_BIT is 16,
and others where CHAR_BIT is 32. In both cases sizeof(char) is 1, by
definition, and it always will be.
Finally, whoever told you that void main(void) is not valid C? I recommend
you get a copy of K&R and read it.
ipo

I have copies of K&R, both the first and second editions. In fact the
rare first printing of the second edition. My original K&R no longer
qualifies for the once-common nickname "the white book", as 25 years
have added a distinctly yellowish color to its pages.

However, in those 25 years, I might have missed something. Can you
provide a quotation from any edition of K&R where they state that
"void main()" is corrects? I thought not.

And you're still top posting, which is still ill-mannered.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

[Jack Klein]

On Sat, 06 Sep 2003 21:27:42 -0700, "E. Robert Tisdale"
<E.**************@jpl.nasa.gov> wrote in comp.lang.c:

Jack Klein wrote:

NEVER cast the pointer returned by malloc() in C.
It is not necessary if <stdlib.h> has been included
and can hide a valuable warning if <stdlib.h> has not been included.

That's *not* the best advice
if you need to compile your code with a C++ compiler:

There is actually nothing at all wrong with writing C code to compile
as C++. One of Bjarne Stroustrup's original purposes in the
development was to create a "better C", and from some points of view
he succeeded quite well.

Nevertheless, C code that compiles with a C++ compiler and produces an
executable with identical results limits one to a subset of C (not
just a subset of C++), and a much smaller one than most people
realize.

The biggest problem with your mention of "if you need to compiler your
code with a C++ compiler" is that it is just plain off-topic here.
Just as much off-topic as discussing attempts to write C code to
compile with a FORTRAN or Lisp compiler.

As far as this newsgroup and the C language are concerned, the
existence of the C++ programming language has been recognized since
October 1999 in the current C standard by references in four foot
notes, and foot notes are not normative:

"182) C++ implementations should define these macros only when
__STDC_FORMAT_MACROS is defined before <inttypes.h> is included."

"217) C++ implementations should define these macros only when
__STDC_LIMIT_MACROS is defined before <stdint.h> is included."

"218) C++ implementations should define these macros only when
__STDC_LIMIT_MACROS is defined before <stdint.h> is included."

"220) C++ implementations should define these macros only when
__STDC_CONSTANT_MACROS is defined before <stdint.h> is included."

Sadly, the topic of writing code that executes with the same results
when compiled with both C and C++ compilers if not particularly
welcome in C++ groups either, as there will likely be many responses
along the lines of "use this or that C++ feature instead."

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

[Joona I Palaste]

Jack Klein <ja*******@spamcop.net> scribbled the following:

On Sat, 06 Sep 2003 21:27:42 -0700, "E. Robert Tisdale"
<E.**************@jpl.nasa.gov> wrote in comp.lang.c:

Jack Klein wrote:

> NEVER cast the pointer returned by malloc() in C.
> It is not necessary if <stdlib.h> has been included
> and can hide a valuable warning if <stdlib.h> has not been included.
That's *not* the best advice
if you need to compile your code with a C++ compiler:

There is actually nothing at all wrong with writing C code to compile
as C++. One of Bjarne Stroustrup's original purposes in the
development was to create a "better C", and from some points of view
he succeeded quite well. Nevertheless, C code that compiles with a C++ compiler and produces an
executable with identical results limits one to a subset of C (not
just a subset of C++), and a much smaller one than most people
realize. The biggest problem with your mention of "if you need to compiler your
code with a C++ compiler" is that it is just plain off-topic here.
Just as much off-topic as discussing attempts to write C code to
compile with a FORTRAN or Lisp compiler. As far as this newsgroup and the C language are concerned, the
existence of the C++ programming language has been recognized since
October 1999 in the current C standard by references in four foot
notes, and foot notes are not normative: "182) C++ implementations should define these macros only when
__STDC_FORMAT_MACROS is defined before <inttypes.h> is included." "217) C++ implementations should define these macros only when
__STDC_LIMIT_MACROS is defined before <stdint.h> is included." "218) C++ implementations should define these macros only when
__STDC_LIMIT_MACROS is defined before <stdint.h> is included." "220) C++ implementations should define these macros only when
__STDC_CONSTANT_MACROS is defined before <stdint.h> is included." Sadly, the topic of writing code that executes with the same results
when compiled with both C and C++ compilers if not particularly
welcome in C++ groups either, as there will likely be many responses
along the lines of "use this or that C++ feature instead."

The problem I see with ERT's remark, and remarks of that kind, is that
they require clairvoyance. Suppose some day someone develops a "sort-of"
superset of C++, or another "sort-of" superset of C? Should we already
begin to write C programs (or C++ programs) that would work correctly
in that?

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Make money fast! Don't feed it!"
- Anon

[ipo]

"Jack Klein" <ja*******@spamcop.net> wrote in message
news:b2********************************@4ax.com...

On Sat, 06 Sep 2003 06:15:31 GMT, "ipo" <ip********@netscape.net>
wrote in comp.lang.c:

FYI:

1. malloc() returns a void pointer and there is absolutely nothing wrong
with using a type cast on the return value. In case you did not know,
stdlib.h has nothing to do with casting. Whether you decide to cast or not any decent compiler will generate a warning and assume a return value of int

Every character that a programmer types into a source code file
increases the possibility for a code defect. Redundant casts are
particularly high on that list.

I do agree with your comments but I also think that some assumptions were
made in your replies as well as mine. I also happen to own a first printing
of K&R78 and if you turn to page 133 you will see that the authors make use
of an explicit cast on the pointer returned by the alloc() function that
they introduce elsewhere in the text. As my replies were addressing the
practice in the context of K&R78, I hope that this will serve to clarify any
difference of opinion..
As for your second assertion, a diagnostic is required if you assign
the return value of an unprototyped function to any type of pointer.
No such diagnostic is required in the presence of a cast.

As for "decent", I have seen many compilers that can be configured to
output a diagnostic message for a call to any function without a
prototype in scope. Sadly, many programmers do not configure their
compilers to operate that way. But I have never seen any compiler
that issues a specific warning for this particular scenario, and at
least a few of the compilers I have used over the decades are
"decent".

for malloc() if stdlib.h is not included.

2. By definition sizeof(char) maybe 1 in your machine. Not mine. So make
sure to use sizeof(char) to be portable.
Then you are posting in the wrong newsgroup, because you are not using
a C compiler. I use compilers for architectures where CHAR_BIT is 16,
and others where CHAR_BIT is 32. In both cases sizeof(char) is 1, by
definition, and it always will be.

You're absolutely right. Please refer to my previous posting where I
admitted my error.
Finally, whoever told you that void main(void) is not valid C? I recommend you get a copy of K&R and read it.
ipo

I have copies of K&R, both the first and second editions. In fact the
rare first printing of the second edition. My original K&R no longer
qualifies for the once-common nickname "the white book", as 25 years
have added a distinctly yellowish color to its pages.

However, in those 25 years, I might have missed something. Can you
provide a quotation from any edition of K&R where they state that
"void main()" is corrects? I thought not.

It is also true that I will not be able to provide you with an example from
either text. If my memory serves me right, the type specifier void was not
even part of the specification that was in place at the time of the first
printing. However, note that Section 5.1.2.2.1.1 of the ISO C Standard
(ISO/IEC 9899:1999) does allow for the definition of void main(), even if at
the price of portability.
And you're still top posting, which is still ill-mannered.

I welcome your criticisms as well as everybody else's but just as you find
my top posting ill-mannered so I find people raising their voice. When
criticized constructively I will be the first to acknowledge his mistakes.

ipo
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq