IS this a proper way of freeing memory with free()

[Raman]

Hi All,

Here is a small Code,

int main(void)
{
char *p=(char *) malloc(100);
strcpy(p,"Test1234567890");
p=p+10;
free(p);
/*** Is here a memory Leak, because p is now
pointing 10 location past to the start of allocated memory
****/

/** some stuff with p again**/


}
Thanks and Regards,
Raman Chalotra

[Yevgen Muntyan]

santosh wrote:

Yevgen Muntyan wrote:

>Richard Bos wrote:

>>Yevgen Muntyan <mu****************@tamu.eduwrote:
Richard Bos wrote:
Ryan Ply <th******@earthling.netwrote:
>rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
>>
>>I don't use Emac-OS, and even if I did, abrv. mode would not solve the
>>more important problem of making the malloc()-caster less attentive. As
>>for "solving" the warnings, that's like "solving" a stinging pain in
>>your right side by taking morphine. Yes, it _does_ get rid of the pain,
>>but you'll still die of a burst appendix sooner or later. It's better
>>get rid of the cause of the pain (read: warning messages) than to ignore
>>it.
>People just like reading whatever they want instead of whats on the
>screen in front of them. Someone said that by casting it would hide or
>mask the compilers warnings to me. I put extra flags in so that these
>warnings return as if nothing happened. Thus "solved".
Wrong.
What's wrong?

<snip>

>>>Are there other other reasons not to cast
RTFThread. It's right up there ^^^.

Sorry, I've seen only one bad thing - suppressing warnings. I might
have missed something, of course. I've seen "cast hides the problems",
but what problems? If compiler warns you about missing prototype, you
add missing #include, and then you're totally good - prototype is in
place, casting void* to whatever* is fine; if whatever* is not the
right type you get another warning (or compilation error). What exactly
are those problems?

Without a prototype, *alloc() are assumed to return an int. They, of
course, return a void pointer value. Assigning an int value, which is
itself derived from a void pointer value, to a pointer to T should
produce a diagnostic, if not for the unneccessary cast. So the casting
hides the fact that no prototype is in scope, and it forces a type
conversion which is not guaranteed to produce meaningful results on
all implementations.

Okay, let me repeat: casting does *not* hide the warning about missing
prototype here. It does suppress the warning about converting int to
pointer, but there is a warning about missing prototype. It *is* there.
So, if you do

int main (void)
{
char *ptr = (char*) malloc(10);
return 0;
}

then you don't get warning about converting int to pointer, but it's not
a problem. Because: you get real warning about real problem, namely
about missing prototype. Warning about converting int to a pointer is
just a side effect when you miss needed #include. You get a warning
about *real* problem, you fix the *real* problem, and then you don't
care about bogus warning about some casts.

I said about it twice, and Ryan Ply said about it at least twice. Try
yourself 'gcc -W -Wall' if you don't believe it.

Yevgen

[Walter Roberson]

In article <ahoyh.11207$MH2.5890@trnddc03>,
Yevgen Muntyan <mu****************@tamu.eduwrote:

>Okay, let me repeat: casting does *not* hide the warning about missing
prototype here. It does suppress the warning about converting int to
pointer, but there is a warning about missing prototype. It *is* there.

>I said about it twice, and Ryan Ply said about it at least twice. Try
yourself 'gcc -W -Wall' if you don't believe it.

I don't use gcc, and you are presuming an awful lot about the properties
of the compilers that I do use.

There is no requirement that an implementation produce a diagnostic
for a missing prototype.
--
Okay, buzzwords only. Two syllables, tops. -- Laurie Anderson

[santosh]

Yevgen Muntyan wrote:

santosh wrote:

Yevgen Muntyan wrote:

Richard Bos wrote:
Yevgen Muntyan wrote:

<snip>

>>Are there other other reasons not to cast

RTFThread. It's right up there ^^^.

Sorry, I've seen only one bad thing - suppressing warnings. I might
have missed something, of course. I've seen "cast hides the problems",
but what problems? If compiler warns you about missing prototype, you
add missing #include, and then you're totally good - prototype is in
place, casting void* to whatever* is fine; if whatever* is not the
right type you get another warning (or compilation error). What exactly
are those problems?

Without a prototype, *alloc() are assumed to return an int. They, of
course, return a void pointer value. Assigning an int value, which is
itself derived from a void pointer value, to a pointer to T should
produce a diagnostic, if not for the unneccessary cast. So the casting
hides the fact that no prototype is in scope, and it forces a type
conversion which is not guaranteed to produce meaningful results on
all implementations.

Okay, let me repeat: casting does *not* hide the warning about missing
prototype here. It does suppress the warning about converting int to
pointer, but there is a warning about missing prototype. It *is* there.

Is such a diagnostic required by the standard? If not, then casting
*does* complicate the discovery of the potential bug by silencing the
compiler with regards to another dangerous construct.

Besides since a void pointer is convertable to a pointer to any type,
why is the cast neccessary in the first place?

[Charlton Wilbur]

>>>>"s" == santosh <sa*********@gmail.comwrites:

sBesides since a void pointer is convertable to a pointer to any
stype, why is the cast neccessary in the first place?

Because C++ decided to make the implicit cast from void * to another
pointer type a semantic error.

When you see a programmer painstakingly casting the return value from
malloc(), you can be sure he imprinted on C++ or was taught by people
who did. Old habits die hard.

Charlton

--
Charlton Wilbur
cw*****@chromatico.net

[Ben Pfaff]

Charlton Wilbur <cw*****@chromatico.netwrites:

When you see a programmer painstakingly casting the return value from
malloc(), you can be sure he imprinted on C++ or was taught by people
who did. Old habits die hard.

Or that he started out with pre-ANSI C, some versions of which
also required the cast.
--
"When I have to rely on inadequacy, I prefer it to be my own."
--Richard Heathfield

[CBFalconer]

Yevgen Muntyan wrote:

>

.... snip ...

>
Okay, let me repeat: casting does *not* hide the warning about
missing prototype here. It does suppress the warning about
converting int to pointer, but there is a warning about missing
prototype. It *is* there. So, if you do

int main (void)
{
char *ptr = (char*) malloc(10);
return 0;
}

then you don't get warning about converting int to pointer, but
it's not a problem. Because: you get real warning about real
problem, namely about missing prototype. Warning about converting
int to a pointer is just a side effect when you miss needed
#include. You get a warning about *real* problem, you fix the
*real* problem, and then you don't care about bogus warning about
some casts.

After deleting the useless and potentially harmful cast, we get:

junk.c: In function `main':
junk.c:3: warning: implicit declaration of function `malloc'
junk.c:3: warning: initialization makes pointer from integer
without a cast
junk.c:3: warning: unused variable `ptr'

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

[Mark McIntyre]

On Wed, 07 Feb 2007 17:47:50 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:

>Okay, let me repeat: casting does *not* hide the warning about missing
prototype here.

agreed.

>It does suppress the warning about converting int to
pointer,

which arises because of hte missing prototype.

>but there is a warning about missing prototype. It *is* there.

In C89 there's no requirement for a prototype to be in scope. A
compiler can complain about it, but its a QoI issue not an actual
error.

>I said about it twice, and Ryan Ply said about it at least twice. Try
yourself 'gcc -W -Wall' if you don't believe it.

You may have said it twice, but that just makes it twice as
inaccurate!
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Yevgen Muntyan]

Mark McIntyre wrote:

On Wed, 07 Feb 2007 17:47:50 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:

>Okay, let me repeat: casting does *not* hide the warning about missing
prototype here.

agreed.

>It does suppress the warning about converting int to
pointer,

which arises because of hte missing prototype.

>but there is a warning about missing prototype. It *is* there.

In C89 there's no requirement for a prototype to be in scope. A
compiler can complain about it, but its a QoI issue not an actual
error.

>I said about it twice, and Ryan Ply said about it at least twice. Try
yourself 'gcc -W -Wall' if you don't believe it.

You may have said it twice, but that just makes it twice as
inaccurate!

Okay, it's really funny how people read not what's written.
I am *not* saying any compiler must emit warning about missing
prototype. I am saying gcc does it when you use -W -Wall.
And Ryan Ply said he uses appropriate compiler flags to get
the warning.

Me: I am fine here, I make gcc take care of this.
You: No, you're wrong. anycc is not obliged to emit a warning.
Me: *I* make *gcc* take care of this *here*.
You: No, you're wrong. See above.

Yevgen

[Yevgen Muntyan]

CBFalconer wrote:

Yevgen Muntyan wrote:
... snip ...

>Okay, let me repeat: casting does *not* hide the warning about
missing prototype here. It does suppress the warning about
converting int to pointer, but there is a warning about missing
prototype. It *is* there. So, if you do

int main (void)
{
char *ptr = (char*) malloc(10);
return 0;
}

then you don't get warning about converting int to pointer, but
it's not a problem. Because: you get real warning about real
problem, namely about missing prototype. Warning about converting
int to a pointer is just a side effect when you miss needed
#include. You get a warning about *real* problem, you fix the
*real* problem, and then you don't care about bogus warning about
some casts.

After deleting the useless and potentially harmful cast, we get:

junk.c: In function `main':
junk.c:3: warning: implicit declaration of function `malloc'
junk.c:3: warning: initialization makes pointer from integer
without a cast
junk.c:3: warning: unused variable `ptr'

Yep, "implicit declaration of function `malloc'". The warning
about actual problem - missing include. You fix the problem and
you're good.

Yevgen

[Christopher Layne]

Yevgen Muntyan wrote:

Okay, it's really funny how people read not what's written.
I am *not* saying any compiler must emit warning about missing
prototype. I am saying gcc does it when you use -W -Wall.
And Ryan Ply said he uses appropriate compiler flags to get
the warning.

IF you use -W. A lot of people just use -Wall.
I don't get the issue here. How about just not cast the return from malloc()
in the first place because it's a pointless thing to do? Not changing that is
just plain refusal to change.

[Yevgen Muntyan]

Walter Roberson wrote:

In article <ahoyh.11207$MH2.5890@trnddc03>,
Yevgen Muntyan <mu****************@tamu.eduwrote:

>Okay, let me repeat: casting does *not* hide the warning about missing
prototype here. It does suppress the warning about converting int to
pointer, but there is a warning about missing prototype. It *is* there.

>I said about it twice, and Ryan Ply said about it at least twice. Try
yourself 'gcc -W -Wall' if you don't believe it.

I don't use gcc, and you are presuming an awful lot about the properties
of the compilers that I do use.

So you don't use gcc and your compiler doesn't have a warning about
missing declarations (I doubt it), fine. You don't want the cast.
Did I tell *you* should cast?

Thing is that bunch of people jumped onto Ryan Ply saying he
does a bad thing and everything, though it wasn't the case. Those
people (including you apparently, because I didnt' say anything
about your compiler and you're saying I am presuming something
about it) did not read what Ryan actually said. And then they
magically translated "I do it this way" into "You all shall do
it this way".

I am not saying "you should cast". I am saying "Ryan Ply is fine
because he knows what he is doing and he is doing a right thing". The
"don't cast result of malloc" is a good rule of thumb in general. But
there are situations (like this one) when cast is harmless, and might
be actually needed. Maybe one wants to compile it with C++ compiler,
or he likes the cast, the cast is valid and correct. And, it
does *not* suppress the warning about the *real* problem, the
problem of not including needed header.

There is no requirement that an implementation produce a diagnostic
for a missing prototype.

I didn't say there is such a requirement. Did I or someone else say it?
The problem is that Ryan said one thing ("works fine for me because
I make it so explicitely") and you all treated him like an fool which
doesn't read the FAQ or something.

Yevgen

[Yevgen Muntyan]

Christopher Layne wrote:

Yevgen Muntyan wrote:

>Okay, it's really funny how people read not what's written.
I am *not* saying any compiler must emit warning about missing
prototype. I am saying gcc does it when you use -W -Wall.
And Ryan Ply said he uses appropriate compiler flags to get
the warning.

IF you use -W. A lot of people just use -Wall.

Who said anything about those people?

I don't get the issue here. How about just not cast the return from malloc()
in the first place because it's a pointless thing to do? Not changing that is
just plain refusal to change.

The whole issue is about people in this thread who can't
understand that original thing was about particular original
thing, not about rules of thumb.

Yes, needless casting is no good. But, casting may be 1) needed,
2) desired for whatever ridiculous reason the author pleases.
Now, if this particular person uses the cast and uses the appropriate
compiler flags when compiling his code, then he's safe. If I use
-W -Wall, I get that warning (not mandated by the standard blah blah)
and I am safe. No, I am not saying everybody should use cast there.

It's just ridiculous what you're saying: "Not changing that is just
plain refusal to change." If you change your code when you're told
so by people who can't read, then it's your personal business. But
it's a stupid thing to do, for sure.

How about compiling with C++ compiler? Remove cast and get an error?
Because "you didn't refuse to change"? Nonsense.

Yevgen

[Christopher Layne]

Yevgen Muntyan wrote:

The whole issue is about people in this thread who can't
understand that original thing was about particular original
thing, not about rules of thumb.

Original pointless thing to do, you mean. "Because it makes me feel good."

Yes, needless casting is no good. But, casting may be 1) needed,
2) desired for whatever ridiculous reason the author pleases.
Now, if this particular person uses the cast and uses the appropriate
compiler flags when compiling his code, then he's safe. If I use
-W -Wall, I get that warning (not mandated by the standard blah blah)
and I am safe. No, I am not saying everybody should use cast there.

In response to "1", give me an example of where casting the return value from
malloc(), calloc(), or realloc() is needed in ISO C.

It's just ridiculous what you're saying: "Not changing that is just
plain refusal to change." If you change your code when you're told
so by people who can't read, then it's your personal business. But
it's a stupid thing to do, for sure.

How about compiling with C++ compiler? Remove cast and get an error?
Because "you didn't refuse to change"? Nonsense.

This isn't C++ here.

[Christopher Layne]

Yevgen Muntyan wrote:

I didn't say there is such a requirement. Did I or someone else say it?
The problem is that Ryan said one thing ("works fine for me because
I make it so explicitely") and you all treated him like an fool which
doesn't read the FAQ or something.

Yevgen

Do you always voraciously support the underdog, or just when the issue hits
home for you?

[Yevgen Muntyan]

Christopher Layne wrote:

Yevgen Muntyan wrote:

>The whole issue is about people in this thread who can't
understand that original thing was about particular original
thing, not about rules of thumb.

Original pointless thing to do, you mean. "Because it makes me feel good."

Even if so, what is so bad about it? If one finds code with cast more
readable, then the cast is good for him (you can try to read the
thread, you'll see what I am talking about). No, it's not a pointless
thing.

>Yes, needless casting is no good. But, casting may be 1) needed,
2) desired for whatever ridiculous reason the author pleases.
Now, if this particular person uses the cast and uses the appropriate
compiler flags when compiling his code, then he's safe. If I use
-W -Wall, I get that warning (not mandated by the standard blah blah)
and I am safe. No, I am not saying everybody should use cast there.

In response to "1", give me an example of where casting the return value from
malloc(), calloc(), or realloc() is needed in ISO C.

Well, see below. How about 2) anyway?

>It's just ridiculous what you're saying: "Not changing that is just
plain refusal to change." If you change your code when you're told
so by people who can't read, then it's your personal business. But
it's a stupid thing to do, for sure.

How about compiling with C++ compiler? Remove cast and get an error?
Because "you didn't refuse to change"? Nonsense.

This isn't C++ here.

Same thing again, huh? "here" means what? I can compile C code with
C++ compiler *here*, and I may want my *C* code to be compilable
with C++ compiler, now what? Come on, I am not going to try to convince
*you* that *you* want the cast. Just because I don't think so.
What I am trying to do is to convince you that *I* may want to
do that evil thing, and I am still fine doing that evil thing.
Because I use compiler flags lalala, lalala, and so on.

[Christopher Layne]

Yevgen Muntyan wrote:

Christopher Layne wrote:

>Original pointless thing to do, you mean. "Because it makes me feel good."

Even if so, what is so bad about it? If one finds code with cast more
readable, then the cast is good for him (you can try to read the
thread, you'll see what I am talking about). No, it's not a pointless
thing.

Yes, it's still a "makes me feel good" touchy feely reason at this point.
There are better ways if C++ compliance is needed.

>>Yes, needless casting is no good. But, casting may be 1) needed,
2) desired for whatever ridiculous reason the author pleases.
Now, if this particular person uses the cast and uses the appropriate
compiler flags when compiling his code, then he's safe. If I use
-W -Wall, I get that warning (not mandated by the standard blah blah)
and I am safe. No, I am not saying everybody should use cast there.

In response to "1", give me an example of where casting the return value
from malloc(), calloc(), or realloc() is needed in ISO C.

Well, see below. How about 2) anyway?

In reference to your "see below" that isn't ISO C, it's defensive programming
to C++ compilers (when you should really be using extern "C").

"For whatever one pleases" doesn't jive when you're dealing with sharing code
and/or a group environment.

>This isn't C++ here.

Same thing again, huh? "here" means what? I can compile C code with
C++ compiler *here*, and I may want my *C* code to be compilable
with C++ compiler, now what? Come on, I am not going to try to convince
*you* that *you* want the cast. Just because I don't think so.
What I am trying to do is to convince you that *I* may want to
do that evil thing, and I am still fine doing that evil thing.
Because I use compiler flags lalala, lalala, and so on.

Cmon dude, extern "C" { }
You keep wanting to facillitate an all-emcompassing method to support what you
want to do - when you aren't even advocating the right way in the first
place.

Compiler flags to catch a malloc casting issue when you should just a: not
cast malloc, b: declare your C code as just that if you're compiling it
within a C++ environment.

Mandating -W as a way "handling" things is nothing but a goofy workaround.

[Yevgen Muntyan]

Christopher Layne wrote:

Yevgen Muntyan wrote:

>I didn't say there is such a requirement. Did I or someone else say it?
The problem is that Ryan said one thing ("works fine for me because
I make it so explicitely") and you all treated him like an fool which
doesn't read the FAQ or something.

Yevgen

Do you always voraciously support the underdog, or just when the issue hits
home for you?

I don't know what "underdog" means, so I can't tell. I can tell though
that I dislike this "mainstream" thing in this newsgroup, when people
get template responses and get *flamed* when try to defend themselves,
even if they are right.
And it does concern me. The last thing I remember is

int *ptr = malloc (10 * sizeof (int));

It's declared heretic here, and you shall not do it, you must
do

int *ptr = malloc (10 * sizeof *ptr);

in any code snippet you post, otherwise you'll get bunch of senseless
replies about why the former is bad. Even if you ask about the
different line of code. It's silly, but when you post a piece of code
in this newsgroup, you have to think not only about its correctness but
also about lot of irrelevant style issues like this. Same thing
with this cast, I wrote a piece of code with such a cast just today,
and I did compile it with g++ and gcc. Happens, you know.

In situations like this I even feel some sympathy to Kenny McSomething.
He's at least an honest troll, not like many people here who insist
on "educating" everybody else and who will throw shit at you if you
refuse to be "educated".

Yevgen

[Yevgen Muntyan]

Christopher Layne wrote:

Yevgen Muntyan wrote:

>Christopher Layne wrote:

>>Original pointless thing to do, you mean. "Because it makes me feel good."

Even if so, what is so bad about it? If one finds code with cast more
readable, then the cast is good for him (you can try to read the
thread, you'll see what I am talking about). No, it's not a pointless
thing.

Yes, it's still a "makes me feel good" touchy feely reason at this point.
There are better ways if C++ compliance is needed.

>>>Yes, needless casting is no good. But, casting may be 1) needed,
2) desired for whatever ridiculous reason the author pleases.
Now, if this particular person uses the cast and uses the appropriate
compiler flags when compiling his code, then he's safe. If I use
-W -Wall, I get that warning (not mandated by the standard blah blah)
and I am safe. No, I am not saying everybody should use cast there.
In response to "1", give me an example of where casting the return value
from malloc(), calloc(), or realloc() is needed in ISO C.

Well, see below. How about 2) anyway?

In reference to your "see below" that isn't ISO C, it's defensive programming
to C++ compilers (when you should really be using extern "C").

"For whatever one pleases" doesn't jive when you're dealing with sharing code
and/or a group environment.

>>This isn't C++ here.

Same thing again, huh? "here" means what? I can compile C code with
C++ compiler *here*, and I may want my *C* code to be compilable
with C++ compiler, now what? Come on, I am not going to try to convince
*you* that *you* want the cast. Just because I don't think so.
What I am trying to do is to convince you that *I* may want to
do that evil thing, and I am still fine doing that evil thing.
Because I use compiler flags lalala, lalala, and so on.

Cmon dude, extern "C" { }
You keep wanting to facillitate an all-emcompassing method to support what you
want to do - when you aren't even advocating the right way in the first
place.

Sorry, what are you talking about? How do you use extern "C" to make
conversion from void* to int* legal?

Compiler flags to catch a malloc casting issue

Ha! You might not know but it's not an issue at all. If you look at
the holy FAQ or something, you'll see that the issue is the missing
#include, and the cast *may* suppress the warning. I know that you
know it though, so nevermind. Let's just remember that it's not
an issue, and nobody is catching it.

when you should just a: not

cast malloc, b: declare your C code as just that if you're compiling it
within a C++ environment.

Please show an example.

Mandating -W as a way "handling" things is nothing but a goofy workaround.

I am not *mandating* anything! I am saying that *if* I use -W -Wall,
then casting return value of malloc() doesn't cause any troubles.
Do you not agree with this one exact sentence?

Yevgen

[CBFalconer]

Yevgen Muntyan wrote:

Christopher Layne wrote:

.... snip ...

>

>This isn't C++ here.

Same thing again, huh? "here" means what? I can compile C code
with C++ compiler *here*, and I may want my *C* code to be
compilable with C++ compiler, now what? Come on, I am not going
to try to convince *you* that *you* want the cast. Just because
I don't think so. What I am trying to do is to convince you that
*I* may want to do that evil thing, and I am still fine doing
that evil thing. Because I use compiler flags lalala, lalala,
and so on.

Do what you wish, but don't recommend bad habits here. There are
innocent newbies around, who might become perverted. That is the
major reason for jumping on such posts.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

[Christopher Layne]

Yevgen Muntyan wrote:

>cast malloc, b: declare your C code as just that if you're compiling it
within a C++ environment.

Please show an example.

>Mandating -W as a way "handling" things is nothing but a goofy workaround.

I am not *mandating* anything! I am saying that *if* I use -W -Wall,
then casting return value of malloc() doesn't cause any troubles.
Do you not agree with this one exact sentence?

Yevgen

$ cat nonsense.c
#include <stdlib.h>

int *nonsense(size_t alot)
{
int *a;

a = malloc(alot * sizeof *a);

return a;
}
$ cat alright.cpp
#include <stdlib.h>

extern "C" {
int *nonsense(size_t);
}

int main(void)
{
int *a;

a = nonsense(456);
if (a) free(a);

return 0;
}
$ gcc -W -Wall -pedantic -c nonsense.c
$ g++ -W -Wall -pedantic -c alright.cpp
$ g++ -W -Wall -pedantic -o alright nonsense.o alright.o
$ ./alright
$

But apparently some people still want to compile C code as C++. They're in C++
land and using malloc(), when they should probably be using new? Alright.

[Christopher Layne]

Yevgen Muntyan wrote:

I don't know what "underdog" means, so I can't tell. I can tell though
that I dislike this "mainstream" thing in this newsgroup, when people
get template responses and get *flamed* when try to defend themselves,
even if they are right.

I'm the last person to be part of any clique here.

And it does concern me. The last thing I remember is

int *ptr = malloc (10 * sizeof (int));

It's declared heretic here, and you shall not do it, you must
do

int *ptr = malloc (10 * sizeof *ptr);

Because it promotes bad habits! That's the entire point. If you change the
type of "ptr" then you must change the sizeof as well. If you do not happen
to remember changing the sizeof (because it's not on the same line, e.g.,
you're a C coder and not just throwing malloc into the declaration AND
definition because it's a: not a typical idiom, b: you won't know how much to
allocate until later, c: you value context of use rather than "well I know
I'll probably be using this later, so let's just allocate now") in the
malloc() statement. This has bitten every single person in this newsgroup
until they learned not to use that construct.

It's like you're at a motorcycle safety school trying to argue why wheelies
should be allowed on public motorways. Nobody is going to buy it there.

In situations like this I even feel some sympathy to Kenny McSomething.
He's at least an honest troll, not like many people here who insist
on "educating" everybody else and who will throw shit at you if you
refuse to be "educated".

I agree with Kenny on other points as well, but like I said: promotes bad
habits.

[Yevgen Muntyan]

Christopher Layne wrote:

Yevgen Muntyan wrote:

>I don't know what "underdog" means, so I can't tell. I can tell though
that I dislike this "mainstream" thing in this newsgroup, when people
get template responses and get *flamed* when try to defend themselves,
even if they are right.

I'm the last person to be part of any clique here.

>And it does concern me. The last thing I remember is

int *ptr = malloc (10 * sizeof (int));

It's declared heretic here, and you shall not do it, you must
do

int *ptr = malloc (10 * sizeof *ptr);

Because it promotes bad habits! That's the entire point. If you change the
type of "ptr" then you must change the sizeof as well.

And if you change the name, you have to change it twice. And if you look
at

ptr = malloc (10 * sizeof *ptr);

then you don't know how much is allocated, while 10*sizeof(int) means
"ten ints". And if you use spaces instead of tabs, then you're wrong
because you must use tabs.
(Oh, and if suddenly *ptr is simply wrong there, then it's an advanced
code and we are not discussing advanced situations here, sure).

If you do not happen
to remember changing the sizeof (because it's not on the same line, e.g.,
you're a C coder and not just throwing malloc into the declaration AND
definition because it's

You better don't throw malloc in your code at all. If it's strings, you
don't need sizeof. If it's anything else, you better be careful. And if
it's structures, you better isolate allocation to some special functions
(where you simply don't care what form you use).

a: not a typical idiom, b: you won't know how much to
allocate until later, c: you value context of use rather than "well I know
I'll probably be using this later, so let's just allocate now") in the
malloc() statement. This has bitten every single person in this newsgroup
until they learned not to use that construct.

The last sentence is not true. And it's not just me who wasn't bitten
by that (I simply don't use raw malloc() much though).

It's like you're at a motorcycle safety school trying to argue why wheelies
should be allowed on public motorways. Nobody is going to buy it there.

No no, not on public anything. On my own yard, my own one-wheel
motorcycle is fine because of have additional safety measures.

>In situations like this I even feel some sympathy to Kenny McSomething.
He's at least an honest troll, not like many people here who insist
on "educating" everybody else and who will throw shit at you if you
refuse to be "educated".

I agree with Kenny on other points as well, but like I said: promotes bad
habits.

What promotes bad habits? Bad habits? Okay, let it be a bad habit to
cast return value of malloc (which I agree with if it's "always
cast"). Do you say that it's fine to claim that the cast in the
following code

#include <stdlib.h>
int main (void)
{
char *foo = (char*) malloc (18);
return 0;
}

*necessarily* and *always* leads to bad results for every single person
in every single situation? Please don't say about habits, just say "yes"
or "no" (and read the thread to see what I am talking about if you're
interested).

Yevgen

[Yevgen Muntyan]

CBFalconer wrote:

Yevgen Muntyan wrote:

>Christopher Layne wrote:

... snip ...

>>This isn't C++ here.

Same thing again, huh? "here" means what? I can compile C code
with C++ compiler *here*, and I may want my *C* code to be
compilable with C++ compiler, now what? Come on, I am not going
to try to convince *you* that *you* want the cast. Just because
I don't think so. What I am trying to do is to convince you that
*I* may want to do that evil thing, and I am still fine doing
that evil thing. Because I use compiler flags lalala, lalala,
and so on.

Do what you wish, but don't recommend bad habits here. There are
innocent newbies around, who might become perverted. That is the
major reason for jumping on such posts.

"Innocent newbies"! Think about it next time when you post
not strictly conforming code here. You may hurt some
newbies who can believe that's "C language as defined
by the standard"!
Seriously speaking, if one cares about newbies and wants
to prevent them from learning something bad, he must
say so, he must not say "You're wrong period". Simply
because "You're wrong period" claim is wrong, and poor
newbies who trust everyone will learn wrong things.
Good one, by the way. "Major reason for jumping on such
posts", yeah.

Yevgen

[Mark McIntyre]

On Thu, 08 Feb 2007 01:36:11 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:

>
Me: I am fine here, I make gcc take care of this.
You: No, you're wrong. anycc is not obliged to emit a warning.
Me: *I* make *gcc* take care of this *here*.
You: No, you're wrong. See above.

You: its ok, I always put the safety on.
Me: its still dangerous, safetys don't always work.
You: *I* always make sure the safety is *on*. So there.
Me: I wouldn't do -
<sfx>*BANG* </>
You: urk.
Me: oh well, Darwin in action.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Flash Gordon]

Yevgen Muntyan wrote, On 08/02/07 13:34:

Christopher Layne wrote:

>Yevgen Muntyan wrote:

>>I don't know what "underdog" means, so I can't tell. I can tell though
that I dislike this "mainstream" thing in this newsgroup, when people
get template responses and get *flamed* when try to defend themselves,
even if they are right.

I'm the last person to be part of any clique here.

>>And it does concern me. The last thing I remember is

int *ptr = malloc (10 * sizeof (int));

It's declared heretic here, and you shall not do it, you must
do

int *ptr = malloc (10 * sizeof *ptr);

Because it promotes bad habits! That's the entire point. If you change
the
type of "ptr" then you must change the sizeof as well.

And if you change the name, you have to change it twice. And if you look
at

ptr = malloc (10 * sizeof *ptr);

then you don't know how much is allocated, while 10*sizeof(int) means
"ten ints". And if you use spaces instead of tabs, then you're wrong
because you must use tabs.
(Oh, and if suddenly *ptr is simply wrong there, then it's an advanced
code and we are not discussing advanced situations here, sure).

This is more obviously a problem
newptr = malloc( 10 * sizeof *oldptr);
than
ptr = malloc( 10 * sizeof(int)

Also with most editors it is easier to do an interactive search and
replace on a variable name that a type name and get it right. Unless you
want to change all int variables to doubles!

>If you do not happen
to remember changing the sizeof (because it's not on the same line, e.g.,
you're a C coder and not just throwing malloc into the declaration AND
definition because it's

You better don't throw malloc in your code at all. If it's strings, you
don't need sizeof. If it's anything else, you better be careful. And if
it's structures, you better isolate allocation to some special functions
(where you simply don't care what form you use).

You should not throw anything in your code. You should always place it
there with care and knowing it is needed. You should also delete
anything that is not needed for the simple reason that it is normally
easier to introduce a bug by having something you don't need that by not
having something you do. Note I am not saying absence is never a bug,
but my experience is that deleting things which are not needed on
average decreases the bug count even if you occasionally delete
something that is needed by mistake.

>a: not a typical idiom, b: you won't know how much to
allocate until later, c: you value context of use rather than "well I
know
I'll probably be using this later, so let's just allocate now") in the
malloc() statement. This has bitten every single person in this newsgroup
until they learned not to use that construct.

The last sentence is not true. And it's not just me who wasn't bitten
by that (I simply don't use raw malloc() much though).

It hasn't bitten me but then I have *never* used a cast on the value
returned by malloc in real code.

>It's like you're at a motorcycle safety school trying to argue why
wheelies
should be allowed on public motorways. Nobody is going to buy it there.

No no, not on public anything. On my own yard, my own one-wheel
motorcycle is fine because of have additional safety measures.

If you get in to the habit of doing something potentially dangerous you
are more likely to do it at a time when it really matters than if you
are not in the habit.

>>In situations like this I even feel some sympathy to Kenny McSomething.
He's at least an honest troll, not like many people here who insist
on "educating" everybody else and who will throw shit at you if you
refuse to be "educated".

I agree with Kenny on other points as well, but like I said: promotes bad
habits.

What promotes bad habits? Bad habits? Okay, let it be a bad habit to
cast return value of malloc (which I agree with if it's "always
cast").

Casting is a bad habit. Casting the value returned by malloc is just a
special case with additional reasons why it can hide problems that
*have* caused programs to fail to run on *modern* hardware and OSs.

Do you say that it's fine to claim that the cast in the
following code

#include <stdlib.h>
int main (void)
{
char *foo = (char*) malloc (18);
return 0;
}

*necessarily* and *always* leads to bad results for every single person
in every single situation? Please don't say about habits, just say "yes"
or "no" (and read the thread to see what I am talking about if you're
interested).

It does not always lead to bad results any more than crossing the road
with your eyes closed always leads to bad results. However, the *habit*
of casting is always a bad habit and the habit of casting malloc is
always a bad habit.

I have seen exactly one person come up with a convincing reason why he
should cast the value returned by malloc in his specific situation. That
reason is at least in part due to commercial reality rather than
technical merit.

Note the compatibility with C++ is a bad reason because:
1) In C++ there are better methods than using malloc to get memory
2) C++ defines mechanisms to interface to C code that has been compiled
as C code.
--
Flash Gordon

[matevzb]

On Feb 8, 7:26 am, Christopher Layne <[e-mail]:

Yevgen Muntyan wrote:

I don't know what "underdog" means, so I can't tell. I can tell though
that I dislike this "mainstream" thing in this newsgroup, when people
get template responses and get *flamed* when try to defend themselves,
even if they are right.

I'm the last person to be part of any clique here.

And it does concern me. The last thing I remember is

int *ptr = malloc (10 * sizeof (int));

It's declared heretic here, and you shall not do it, you must
do

int *ptr = malloc (10 * sizeof *ptr);

Because it promotes bad habits! That's the entire point. If you change the
type of "ptr" then you must change the sizeof as well. If you do not happen
to remember changing the sizeof (because it's not on the same line, e.g.,
you're a C coder and not just throwing malloc into the declaration AND
definition because it's a: not a typical idiom, b: you won't know how much to
allocate until later, c: you value context of use rather than "well I know
I'll probably be using this later, so let's just allocate now") in the
malloc() statement. This has bitten every single person in this newsgroup
until they learned not to use that construct.

I tend to disagree on this one. If you change the type of "ptr" you
*should* examine *all* the places where "ptr" was used anyhow (not
just the line with malloc). If you don't, that's promoting bad habits
and that may bite harder than the x*sizeof(<type>). I personally
always use the latter and have never had any trouble with it.

It's like you're at a motorcycle safety school trying to argue why wheelies
should be allowed on public motorways. Nobody is going to buy it there.

Nonsense.
--
WYCIWYG

[Yevgen Muntyan]

Christopher Layne wrote:

Yevgen Muntyan wrote:

>>cast malloc, b: declare your C code as just that if you're compiling it
within a C++ environment.

Please show an example.

>>Mandating -W as a way "handling" things is nothing but a goofy workaround.

I am not *mandating* anything! I am saying that *if* I use -W -Wall,
then casting return value of malloc() doesn't cause any troubles.
Do you not agree with this one exact sentence?

Yevgen

$ cat nonsense.c

[snip an irrelevant example of using g++ to compile C++ sources and
gcc to compile C sources]

But apparently some people still want to compile C code as C++. They're in C++
land and using malloc(), when they should probably be using new? Alright.

I wonder if it was "yes" or "no".
Anyway, there are cases when one wants to compile C code with C++
compiler. The most realistic example is macros in headers. Then inline
functions. Then sources which don't know about __cplusplus and extern
"C". Generated code doesn't count since it's way too advanced, right?
And if one likes to compile C code with C++ compiler to get stricter
type checking, that's a you-shall-not-do-that-just-because thing.
Anyway, C++ compiler is only one thing. You may get the cast
in C code just because it's there, e.g. in third party sources.
And you didn't fix it because you don't like to touch working code. Etc.
See, what you're saying is a reply to "Cast is always good and needed".
But nobody claimed that. And so on, and so forth.
Funny how people can talk about different things in form of dialog,
isn't it?
Perhaps I should have said that I don't think casting return value of
malloc is a good idea? Instead of not-saying which gets interpreted
as saying-the-contrary.

Yevgen

[Yevgen Muntyan]

Mark McIntyre wrote:

On Thu, 08 Feb 2007 01:36:11 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:

>Me: I am fine here, I make gcc take care of this.
You: No, you're wrong. anycc is not obliged to emit a warning.
Me: *I* make *gcc* take care of this *here*.
You: No, you're wrong. See above.

You: its ok, I always put the safety on.
Me: its still dangerous, safetys don't always work.
You: *I* always make sure the safety is *on*. So there.
Me: I wouldn't do -
<sfx>*BANG* </>
You: urk.
Me: oh well, Darwin in action.

Indeed, code tends to break when you don't touch it. You
put cast in, it explodes in two months.
What you're all saying is why it's not a good idea to
use cast. And that's indeed true, it's not a good idea
to cast when you don't have to. What's not true
is that any given piece of code with cast is wrong and
dangerous in any situation.

Yevgen

[Yevgen Muntyan]

Flash Gordon wrote:

Yevgen Muntyan wrote, On 08/02/07 13:34:

>Christopher Layne wrote:

>>Yevgen Muntyan wrote:

I don't know what "underdog" means, so I can't tell. I can tell though
that I dislike this "mainstream" thing in this newsgroup, when people
get template responses and get *flamed* when try to defend themselves,
even if they are right.

I'm the last person to be part of any clique here.

And it does concern me. The last thing I remember is

int *ptr = malloc (10 * sizeof (int));

It's declared heretic here, and you shall not do it, you must
do

int *ptr = malloc (10 * sizeof *ptr);

Because it promotes bad habits! That's the entire point. If you
change the
type of "ptr" then you must change the sizeof as well.

And if you change the name, you have to change it twice. And if you look
at

ptr = malloc (10 * sizeof *ptr);

then you don't know how much is allocated, while 10*sizeof(int) means
"ten ints". And if you use spaces instead of tabs, then you're wrong
because you must use tabs.
(Oh, and if suddenly *ptr is simply wrong there, then it's an advanced
code and we are not discussing advanced situations here, sure).

This is more obviously a problem
newptr = malloc( 10 * sizeof *oldptr);
than
ptr = malloc( 10 * sizeof(int)

Also with most editors it is easier to do an interactive search and
replace on a variable name that a type name and get it right. Unless you
want to change all int variables to doubles!

If you use editor's search to modify code then you'll get errors,
just because this edit is that complex. And you'll get errors
unrelated to malloc() ;)

>

>>If you do not happen
to remember changing the sizeof (because it's not on the same line,
e.g.,
you're a C coder and not just throwing malloc into the declaration AND
definition because it's

You better don't throw malloc in your code at all. If it's strings, you
don't need sizeof. If it's anything else, you better be careful. And if
it's structures, you better isolate allocation to some special functions
(where you simply don't care what form you use).

You should not throw anything in your code. You should always place it
there with care and knowing it is needed. You should also delete
anything that is not needed for the simple reason that it is normally
easier to introduce a bug by having something you don't need that by not
having something you do. Note I am not saying absence is never a bug,
but my experience is that deleting things which are not needed on
average decreases the bug count even if you occasionally delete
something that is needed by mistake.

>>a: not a typical idiom, b: you won't know how much to
allocate until later, c: you value context of use rather than "well I
know
I'll probably be using this later, so let's just allocate now") in the
malloc() statement. This has bitten every single person in this
newsgroup
until they learned not to use that construct.

The last sentence is not true. And it's not just me who wasn't bitten
by that (I simply don't use raw malloc() much though).

It hasn't bitten me but then I have *never* used a cast on the value
returned by malloc in real code.

>>It's like you're at a motorcycle safety school trying to argue why
wheelies
should be allowed on public motorways. Nobody is going to buy it there.

No no, not on public anything. On my own yard, my own one-wheel
motorcycle is fine because of have additional safety measures.

If you get in to the habit of doing something potentially dangerous you
are more likely to do it at a time when it really matters than if you
are not in the habit.

>>>In situations like this I even feel some sympathy to Kenny McSomething.
He's at least an honest troll, not like many people here who insist
on "educating" everybody else and who will throw shit at you if you
refuse to be "educated".

I agree with Kenny on other points as well, but like I said: promotes
bad
habits.

What promotes bad habits? Bad habits? Okay, let it be a bad habit to
cast return value of malloc (which I agree with if it's "always
cast").

Casting is a bad habit. Casting the value returned by malloc is just a
special case with additional reasons why it can hide problems that
*have* caused programs to fail to run on *modern* hardware and OSs.

Do you say that it's fine to claim that the cast in the
following code

#include <stdlib.h>
int main (void)
{
char *foo = (char*) malloc (18);
return 0;
}

*necessarily* and *always* leads to bad results for every single person
in every single situation? Please don't say about habits, just say "yes"
or "no" (and read the thread to see what I am talking about if you're
interested).

It does not always lead to bad results any more than crossing the road
with your eyes closed always leads to bad results.

True statement, just as true as that jumping on the ground is no more
dangerous than jumping off a skyscraper. And so nicely makes it sound
as dangerous even though it doesn't explicitely say so.

However, the *habit*
of casting is always a bad habit and the habit of casting malloc is
always a bad habit.

Yes, such a *habit* is bad. Did I tell it's not?

I have seen exactly one person come up with a convincing reason why he
should cast the value returned by malloc in his specific situation. That
reason is at least in part due to commercial reality rather than
technical merit.

Note the compatibility with C++ is a bad reason because:
1) In C++ there are better methods than using malloc to get memory

You lose compatibility with C then ;)

2) C++ defines mechanisms to interface to C code that has been compiled
as C code.

And I am talking about compiling *C* code with *C++* compiler.

Yevgen

[Mark McIntyre]

On Thu, 08 Feb 2007 12:56:40 -0600, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:

>Mark McIntyre wrote:

>On Thu, 08 Feb 2007 01:36:11 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:

>>Me: I am fine here, I make gcc take care of this.
You: No, you're wrong. anycc is not obliged to emit a warning.
Me: *I* make *gcc* take care of this *here*.
You: No, you're wrong. See above.

You: its ok, I always put the safety on.
Me: its still dangerous, safetys don't always work.
You: *I* always make sure the safety is *on*. So there.
Me: I wouldn't do -
<sfx>*BANG* </>
You: urk.
Me: oh well, Darwin in action.

Indeed, code tends to break when you don't touch it.

I assume you got the point, and are merely trying to avoid it. :-)

>You put cast in, it explodes in two months.

Sure, if during that 2 months, you upgraded your compiler, OS or
target infrastructure.

>What you're all saying is why it's not a good idea to
use cast. And that's indeed true, it's not a good idea
to cast when you don't have to.

And malloc is a case where you don't have to.

>What's not true
is that any given piece of code with cast is wrong and
dangerous in any situation.

Nobody ever said that.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

On Thu, 08 Feb 2007 13:14:44 -0600, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:

Flash wrote

>1) In C++ there are better methods than using malloc to get memory

>You lose compatibility with C then ;)

Yes, people who think C and C++ are compatible often do seem to prefer
sloppy ill-defined compatibility over formal but slightly harder to
use compatibility. Smiley noted.

>2) C++ defines mechanisms to interface to C code that has been compiled
as C code.

>And I am talking about compiling *C* code with *C++* compiler.

If you're compiling it with a C++ compiler, its C++ code. It may look
like C, it may also compile as C, but its C++, and probably badly
written C++ at that.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Ian Collins]

Mark McIntyre wrote:

On Thu, 08 Feb 2007 13:14:44 -0600, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:

>>And I am talking about compiling *C* code with *C++* compiler.

If you're compiling it with a C++ compiler, its C++ code. It may look
like C, it may also compile as C, but its C++, and probably badly
written C++ at that.

Unless you are using C++ constructs to test your C...

--
Ian Collins.

[Chris Torek]

In article <T6yyh.3290$6P4.823@trnddc06>
Yevgen Muntyan <mu****************@tamu.eduwrote:

>I am not *mandating* anything! I am saying that *if* I use -W -Wall,
then casting return value of malloc() doesn't cause any troubles.
Do you not agree with this one exact sentence?

I agree with that sentence. I also agree, however, that it is
possible to mow one's lawn with a flamethrower. I would not
recommend that either. :-)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[CBFalconer]

Yevgen Muntyan wrote:

>

.... snip ...

>
What promotes bad habits? Bad habits? Okay, let it be a bad habit
to cast return value of malloc (which I agree with if it's "always
cast"). Do you say that it's fine to claim that the cast in the
following code

#include <stdlib.h>
int main (void)
{
char *foo = (char*) malloc (18);
return 0;
}

*necessarily* and *always* leads to bad results for every single
person in every single situation? Please don't say about habits,
just say "yes" or "no" (and read the thread to see what I am
talking about if you're interested).

Always. He has typed at least eight unnecessary characters,
leading to broken fingernails, various muscular problems, not to
mention the extraneous discussion here and added probability of
spilling coffee (or other liquids) into the keyboard. The program
is also fatally flawed by failure to #include <stdlib.h>, while the
inclusion of stdio.h is totally unnecessary (another 19 excess
chars typed).

--
Some free news servers. I use teranews and gmane.
<http://www.teranews.com (1 time charge) (free)
<http://news.aioe.org (free)
<http://dotsrc.org (free)
<http://www.x-privat.org/international.php (free)
<http://motzarella.org/?language=en (free)
<http://gmane.org/ (mail-lists via news) (free)
<http://www.newsfeeds.com/signup.htm (pay)
<http://www.individual.net/ (low pay)

[CBFalconer]

Yevgen Muntyan wrote:

Flash Gordon wrote:

.... snip ...

>

>2) C++ defines mechanisms to interface to C code that has been compiled
as C code.

And I am talking about compiling *C* code with *C++* compiler.

This is an extremely silly thing to do. The languages are
different. A C compiler compiles C source, while a C++ compiler
compiles C++ source. There is one regular user of this newsgroup
who follows that practice, because he deals with idiots who do not
know the difference, and the ability avoids support problems
explaining their idiocy in dulcet and inoffensive tones, thus
improving his standard of living.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

[CBFalconer]

matevzb wrote:

>

.... snip ...

>
I tend to disagree on this one. If you change the type of "ptr"
you *should* examine *all* the places where "ptr" was used anyhow
(not just the line with malloc). If you don't, that's promoting
bad habits and that may bite harder than the x*sizeof(<type>). I
personally always use the latter and have never had any trouble
with it.

Not necessary. If you have avoided unnecessary casts, the compiler
will point out any harmful type mismatches.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

[Ian Collins]

CBFalconer wrote:

Yevgen Muntyan wrote:

>>Flash Gordon wrote:

.... snip ...

>>>2) C++ defines mechanisms to interface to C code that has been compiled
as C code.

And I am talking about compiling *C* code with *C++* compiler.

This is an extremely silly thing to do. The languages are
different. A C compiler compiles C source, while a C++ compiler
compiles C++ source. There is one regular user of this newsgroup
who follows that practice, because he deals with idiots who do not
know the difference, and the ability avoids support problems
explaining their idiocy in dulcet and inoffensive tones, thus
improving his standard of living.

You wouldn't be referring to me would you?

If so, what have I done to you to deserve such an ignorant insult?

How can you argue against using C++ objects to simulate hardware in
order to test C device drivers?

--
Ian Collins.

[Flash Gordon]

Yevgen Muntyan wrote, On 08/02/07 19:14:

Flash Gordon wrote:

>Yevgen Muntyan wrote, On 08/02/07 13:34:

>>Christopher Layne wrote:
Yevgen Muntyan wrote:

I don't know what "underdog" means, so I can't tell. I can tell though
that I dislike this "mainstream" thing in this newsgroup, when people
get template responses and get *flamed* when try to defend themselves,
even if they are right.

I'm the last person to be part of any clique here.

And it does concern me. The last thing I remember is
>
int *ptr = malloc (10 * sizeof (int));
>
It's declared heretic here, and you shall not do it, you must
do
>
int *ptr = malloc (10 * sizeof *ptr);

Because it promotes bad habits! That's the entire point. If you
change the
type of "ptr" then you must change the sizeof as well.

And if you change the name, you have to change it twice. And if you look
at

ptr = malloc (10 * sizeof *ptr);

then you don't know how much is allocated, while 10*sizeof(int) means
"ten ints". And if you use spaces instead of tabs, then you're wrong
because you must use tabs.
(Oh, and if suddenly *ptr is simply wrong there, then it's an advanced
code and we are not discussing advanced situations here, sure).

This is more obviously a problem
newptr = malloc( 10 * sizeof *oldptr);
than
ptr = malloc( 10 * sizeof(int)

Also with most editors it is easier to do an interactive search and
replace on a variable name that a type name and get it right. Unless
you want to change all int variables to doubles!

If you use editor's search to modify code then you'll get errors,
just because this edit is that complex. And you'll get errors
unrelated to malloc() ;)

So take the simpler option for editing of using
ptr = malloc(N * sizeof *ptr);

<snip>

>However, the *habit* of casting is always a bad habit and the habit of
casting malloc is always a bad habit.

Yes, such a *habit* is bad. Did I tell it's not?

You seem to be saying there is nothing wrong with doing something even
though if it becomes a habit it is a bad habit. Habits are formed by
repeatedly doing things, so if you want to avoid having bad habits do
not engage in the practices which are bad habits.

>I have seen exactly one person come up with a convincing reason why he
should cast the value returned by malloc in his specific situation.
That reason is at least in part due to commercial reality rather than
technical merit.

Note the compatibility with C++ is a bad reason because:
1) In C++ there are better methods than using malloc to get memory

You lose compatibility with C then ;)

Actually, than is not necessarily true. There are ways of creating
interfaces for C code to call C++ code.

>2) C++ defines mechanisms to interface to C code that has been
compiled as C code.

And I am talking about compiling *C* code with *C++* compiler.

Simple solution, don't do it. Apart from anything else there are subtle
differences between C and C++ such that a program can be valid as both
but behave differently.
--
Flash Gordon

[Keith Thompson]

Ian Collins <ia******@hotmail.comwrites:

CBFalconer wrote:

>Yevgen Muntyan wrote:

>>>Flash Gordon wrote:

.... snip ...

>>>>2) C++ defines mechanisms to interface to C code that has been compiled
as C code.

And I am talking about compiling *C* code with *C++* compiler.

This is an extremely silly thing to do. The languages are
different. A C compiler compiles C source, while a C++ compiler
compiles C++ source. There is one regular user of this newsgroup
who follows that practice, because he deals with idiots who do not
know the difference, and the ability avoids support problems
explaining their idiocy in dulcet and inoffensive tones, thus
improving his standard of living.

You wouldn't be referring to me would you?

[snip]

I'm sure he was referring to P.J. Plauger (though I'm not aware of any
basis for referring to his customers as idiots).

--
Keith Thompson (The_Other_Keith) 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.

[Yevgen Muntyan]

Flash Gordon wrote:

Yevgen Muntyan wrote, On 08/02/07 19:14:

>Flash Gordon wrote:

>>Yevgen Muntyan wrote, On 08/02/07 13:34:
Christopher Layne wrote:
Yevgen Muntyan wrote:
>
>I don't know what "underdog" means, so I can't tell. I can tell
>though
>that I dislike this "mainstream" thing in this newsgroup, when people
>get template responses and get *flamed* when try to defend
>themselves,
>even if they are right.
>
I'm the last person to be part of any clique here.
>
>And it does concern me. The last thing I remember is
>>
>int *ptr = malloc (10 * sizeof (int));
>>
>It's declared heretic here, and you shall not do it, you must
>do
>>
>int *ptr = malloc (10 * sizeof *ptr);
>
Because it promotes bad habits! That's the entire point. If you
change the
type of "ptr" then you must change the sizeof as well.

And if you change the name, you have to change it twice. And if you
look
at

ptr = malloc (10 * sizeof *ptr);

then you don't know how much is allocated, while 10*sizeof(int) means
"ten ints". And if you use spaces instead of tabs, then you're wrong
because you must use tabs.
(Oh, and if suddenly *ptr is simply wrong there, then it's an advanced
code and we are not discussing advanced situations here, sure).

This is more obviously a problem
newptr = malloc( 10 * sizeof *oldptr);
than
ptr = malloc( 10 * sizeof(int)

Also with most editors it is easier to do an interactive search and
replace on a variable name that a type name and get it right. Unless
you want to change all int variables to doubles!

If you use editor's search to modify code then you'll get errors,
just because this edit is that complex. And you'll get errors
unrelated to malloc() ;)

So take the simpler option for editing of using
ptr = malloc(N * sizeof *ptr);

<snip>

>>However, the *habit* of casting is always a bad habit and the habit
of casting malloc is always a bad habit.

Yes, such a *habit* is bad. Did I tell it's not?

You seem to be saying there is nothing wrong with doing something even
though if it becomes a habit it is a bad habit. Habits are formed by
repeatedly doing things, so if you want to avoid having bad habits do
not engage in the practices which are bad habits.

I do not engage in those practices to my best knowledge. At least
not with casting return value of malloc. I don't cast it normally.
I do cast it when I need to (usually it's C++ or allocation
macros in headers). And I am not saying it's okay to cast stuff
here and there. I am saying that some folks in this newsgroup
must apply some consideration and thinking before spitting
stupid "Wrong."

>>I have seen exactly one person come up with a convincing reason why
he should cast the value returned by malloc in his specific
situation. That reason is at least in part due to commercial reality
rather than technical merit.

Note the compatibility with C++ is a bad reason because:
1) In C++ there are better methods than using malloc to get memory

You lose compatibility with C then ;)

Actually, than is not necessarily true. There are ways of creating
interfaces for C code to call C++ code.

Tenth time: *compiling* C code with C++ compiler. It is necessarily
true that C compiler won't accept "new Foo" (we don't talk crazy
"C/C++" compilers and funny macros, right?).

>>2) C++ defines mechanisms to interface to C code that has been
compiled as C code.

And I am talking about compiling *C* code with *C++* compiler.

Simple solution, don't do it. Apart from anything else there are subtle
differences between C and C++ such that a program can be valid as both
but behave differently.

And there is lot of C code which behaves in the same way. E.g.

foo.h:
---------------------------
#ifdef __cplusplus
extern "C" {
#endif

typedef struct Foo Foo;

void *alloc_some_mem (size_t n);

#define ALLOC_FOO() ((Foo*) alloc_some_mem (sizeof (Foo)))

#ifdef __cplusplus
}
#endif
---------------------------

I won't try to talk about other cases when one really wants to compile
his C code with C++ compiler, since there is an easy solution, "don't do
it". I really love these simple solutions: the problem is to do this
and this; the solution is not to do this and this and do that instead.
Works like a charm in an argument.

Yevgen

[Richard Heathfield]

CBFalconer said:

Yevgen Muntyan wrote:

>>

... snip ...

>>
What promotes bad habits? Bad habits? Okay, let it be a bad habit
to cast return value of malloc (which I agree with if it's "always
cast"). Do you say that it's fine to claim that the cast in the
following code

#include <stdlib.h>
int main (void)
{
char *foo = (char*) malloc (18);
return 0;
}

*necessarily* and *always* leads to bad results for every single
person in every single situation? Please don't say about habits,
just say "yes" or "no" (and read the thread to see what I am
talking about if you're interested).

Always. He has typed at least eight unnecessary characters,
leading to broken fingernails, various muscular problems, not to
mention the extraneous discussion here and added probability of
spilling coffee (or other liquids) into the keyboard.

All most droll, Chuck, but...

The program
is also fatally flawed by failure to #include <stdlib.h>

....wrong...

, while the
inclusion of stdio.h is totally unnecessary (another 19 excess
chars typed).

....and wrong again.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Richard Heathfield]

Yevgen Muntyan said:

<snip>

I do not engage in those practices to my best knowledge. At least
not with casting return value of malloc. I don't cast it normally.
I do cast it when I need to

In which case you never cast it, since it's never necessary.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Yevgen Muntyan]

Richard Heathfield wrote:

Yevgen Muntyan said:

<snip>

>I do not engage in those practices to my best knowledge. At least
not with casting return value of malloc. I don't cast it normally.
I do cast it when I need to

In which case you never cast it, since it's never necessary.

You snipped the piece where I said when I need to. Sure, you
can say that I can just avoid using malloc and alike in headers.
The same "simple solution" as was offered elsewhere: avoid
situations where you need cast and you will not need cast.
But I still believe that

#define ALLOC_A_THING(Type) ((Type*) malloc (sizeof (Type)))

is not too bad.

Yevgen

[CBFalconer]

Keith Thompson wrote:

Ian Collins <ia******@hotmail.comwrites:

>CBFalconer wrote:

>>Yevgen Muntyan wrote:
Flash Gordon wrote:

.... snip ...

2) C++ defines mechanisms to interface to C code that has been compiled
as C code.

And I am talking about compiling *C* code with *C++* compiler.

This is an extremely silly thing to do. The languages are
different. A C compiler compiles C source, while a C++ compiler
compiles C++ source. There is one regular user of this newsgroup
who follows that practice, because he deals with idiots who do not
know the difference, and the ability avoids support problems
explaining their idiocy in dulcet and inoffensive tones, thus
improving his standard of living.

You wouldn't be referring to me would you?

[snip]

I'm sure he was referring to P.J. Plauger (though I'm not aware of
any basis for referring to his customers as idiots).

I'm sure some are, otherwise he would not need to proof his
shrouded software against miscompiling.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

[matevzb]

On Feb 8, 11:51 pm, CBFalconer <[e-mail]:

matevzb wrote:

I tend to disagree on this one. If you change the type of "ptr"
you *should* examine *all* the places where "ptr" was used anyhow
(not just the line with malloc). If you don't, that's promoting
bad habits and that may bite harder than the x*sizeof(<type>). I
personally always use the latter and have never had any trouble
with it.

Not necessary. If you have avoided unnecessary casts, the compiler
will point out any harmful type mismatches.

No, it won't in case of void *. A hypothetical case:
#include <stdlib.h>
#include <string.h>

typedef enum
{
SHORT = 0,
LONG = 1
} mytype;

int
fcn (void *array, mytype type, size_t size)
{
void *ptr;

switch (type)
{
case SHORT:
ptr = malloc (size * sizeof(short));
memcpy (ptr, array, size * sizeof(short));
break;

case LONG:
ptr = malloc (size * sizeof(long));
memcpy (ptr, array, size * sizeof(long));
break;

default:
return -1;
}

return 0;
}

int
main (void)
{
long *ptr = malloc (10 * sizeof *ptr);

memset (ptr, 1, 10 * sizeof *ptr);
fcn (ptr, LONG, 10);

return 0;
}

If "ptr" in main() is changed from "long *" to "short *", there will
be no warning (and no casts were used). There will be a bug lurking
however.
--
WYCIWYG - what you C is what you get

[CBFalconer]

Richard Heathfield wrote:

CBFalconer said:

>Yevgen Muntyan wrote:

>>>

... snip ...

>>>
What promotes bad habits? Bad habits? Okay, let it be a bad habit
to cast return value of malloc (which I agree with if it's "always
cast"). Do you say that it's fine to claim that the cast in the
following code

#include <stdlib.h>
int main (void)
{
char *foo = (char*) malloc (18);
return 0;
}

*necessarily* and *always* leads to bad results for every single
person in every single situation? Please don't say about habits,
just say "yes" or "no" (and read the thread to see what I am
talking about if you're interested).

Always. He has typed at least eight unnecessary characters,
leading to broken fingernails, various muscular problems, not to
mention the extraneous discussion here and added probability of
spilling coffee (or other liquids) into the keyboard.

All most droll, Chuck, but...

>The program
is also fatally flawed by failure to #include <stdlib.h>

...wrong...

>, while the
inclusion of stdio.h is totally unnecessary (another 19 excess
chars typed).

...and wrong again.

Damn. I could have sworn I read stdio there. There goes my
perfect record. The nits are getting out of hand.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

[Richard Heathfield]

Yevgen Muntyan said:

Richard Heathfield wrote:

>Yevgen Muntyan said:

<snip>

>>I do not engage in those practices to my best knowledge. At least
not with casting return value of malloc. I don't cast it normally.
I do cast it when I need to

In which case you never cast it, since it's never necessary.

You snipped the piece where I said when I need to.

There is no need to cast malloc, even in a macro.

<snip>

The same "simple solution" as was offered elsewhere: avoid
situations where you need cast and you will not need cast.
But I still believe that

#define ALLOC_A_THING(Type) ((Type*) malloc (sizeof (Type)))

is not too bad.

It's ghastly. It doesn't buy you anything useful. It doesn't encapsulate
anything worth encapsulating.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Ian Collins]

matevzb wrote:

On Feb 8, 11:51 pm, CBFalconer <[e-mail]:

>>matevzb wrote:

>>>I tend to disagree on this one. If you change the type of "ptr"
you *should* examine *all* the places where "ptr" was used anyhow
(not just the line with malloc). If you don't, that's promoting
bad habits and that may bite harder than the x*sizeof(<type>). I
personally always use the latter and have never had any trouble
with it.

Not necessary. If you have avoided unnecessary casts, the compiler
will point out any harmful type mismatches.

No, it won't in case of void *. A hypothetical case:

<snip>

>
If "ptr" in main() is changed from "long *" to "short *", there will
be no warning (and no casts were used). There will be a bug lurking
however.

If you lie to the compiler, what do you expect?

--
Ian Collins.

[Yevgen Muntyan]

Richard Heathfield wrote:

Yevgen Muntyan said:

>Richard Heathfield wrote:

>>Yevgen Muntyan said:

<snip>

I do not engage in those practices to my best knowledge. At least
not with casting return value of malloc. I don't cast it normally.
I do cast it when I need to
In which case you never cast it, since it's never necessary.

You snipped the piece where I said when I need to.

There is no need to cast malloc, even in a macro.

<snip>

>The same "simple solution" as was offered elsewhere: avoid
situations where you need cast and you will not need cast.
But I still believe that

#define ALLOC_A_THING(Type) ((Type*) malloc (sizeof (Type)))

is not too bad.

It's ghastly. It doesn't buy you anything useful. It doesn't encapsulate
anything worth encapsulating.

#define ALLOC_A_THING(Type) ((Type*) custom_allocator_here (sizeof (Type)))

Even with malloc this macro is more convenient than malloc(sizeof *foo)
or malloc(sizeof(Foo)) (given the name is better than
"custom_allocator_here"). Some people even believe it's safer than
raw malloc. Or

#define FOO_NEW() ((Foo*) malloc (sizeof (Foo))) // *must* cast here

Regards,
Yevgen

[Richard Heathfield]

Yevgen Muntyan said:

Richard Heathfield wrote:

>Yevgen Muntyan said:

<snip>

>>But I still believe that

#define ALLOC_A_THING(Type) ((Type*) malloc (sizeof (Type)))

is not too bad.

It's ghastly. It doesn't buy you anything useful. It doesn't
encapsulate anything worth encapsulating.

#define ALLOC_A_THING(Type) ((Type*) custom_allocator_here (sizeof
#(Type)))

Even with malloc this macro is more convenient than malloc(sizeof
*foo) or malloc(sizeof(Foo)) (given the name is better than
"custom_allocator_here").

I fail to see why:

p = ALLOC_A_THING(foo);

is more convenient than:

p = malloc(sizeof *p);

Some people even believe it's safer than raw malloc.

Some people even believe Elvis lives.

Or

#define FOO_NEW() ((Foo*) malloc (sizeof (Foo))) // *must* cast here

Why? The cast doesn't do any good, and in any case this is a lousy way
to create an object of a particular type. You'd be far better off with
a function that could not only reserve storage for the object but also
populate it with its initial value.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.