Yevgen Muntyan wrote, On 08/02/07 13:34:
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!
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.
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.
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.
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.
