473,324 Members | 2,531 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,324 software developers and data experts.

why is casting malloc a bad thing?

Hello,

I saw on a couple of recent posts people saying that casting the return
value of malloc is bad, like:

d=(double *) malloc(50*sizeof(double));

why is this bad? I had always thought (perhaps mistakenly) that the
purpose of a void pointer was to cast into a legitimate date type. Is
this wrong? Why, and what is considered to be correct form?

thanks,

Brian Blais

Nov 14 '05
231 22849
"pete" <pf*****@mindspring.com> wrote in message
news:40***********@mindspring.com...
Richard Bos wrote:

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote:
Mark McIntyre wrote:

> P.J. Plauger wrote:
>
>>If you write malloc calls without casts, it's not because it's
>>necessarily good programming practice
>>but because your grandfather did. But this is the one place where you're an idiot. A complete one.

That's an 'Ad Hominen' argument:
So is Plauger's assertion that those of us who disagree with him do so
out of mere tradition.


Especially since original K&R C used the cast.
The cast is the old way. No cast, is the new way.


Sorry, that's not quite right. The cast wasn't required in many/most
early C compilers. Some compilers experimented with stronger type
checking for pointers (a bit of the prior art we drew on when we
decided it was safe and advisable to add stronger type checking
in Standard C). Some of us felt that better documentation of
intended type conversions was advisable. But for whatever reason,
Kernighan at least went through a period when he saw fit to write
the casts.

Great quantities of code existed without casts on malloc calls.
We knew that people would object violently to being forced to
go through all that code and decorate all mslloc calls with casts.
Of course, there were also great quantities of code that didn't
include all necessary headers to get library functions properly
declared (in many cases relying on representation punning between
default int return types and pointers), but it's way easier to
fixup an old source file by adding a few includes.

So it's both simplistic and incorrect to assert:
The cast is the old way. No cast, is the new way.


Four legs good, two legs bad.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Nov 14 '05 #101
P.J. Plauger wrote:

"pete" <pf*****@mindspring.com> wrote in message
news:40***********@mindspring.com...

The cast is the old way. No cast, is the new way.


Four legs good, two legs bad.


Four legs animal. Two legs man.

--
pete
Nov 14 '05 #102
"pete" <pf*****@mindspring.com> wrote in message
news:40***********@mindspring.com...
P.J. Plauger wrote:

"pete" <pf*****@mindspring.com> wrote in message
news:40***********@mindspring.com...

The cast is the old way. No cast, is the new way.


Four legs good, two legs bad.


Four legs animal. Two legs man.


Really? Remember the ancient riddle: what walks on four legs in
the morning, two legs in the afternoon, and three legs in the
evening?

Few things are as simple as they at first appear.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Nov 14 '05 #103
P.J. Plauger wrote:
"pete" <pf*****@mindspring.com> wrote in message
news:40***********@mindspring.com...
P.J. Plauger wrote:
>
> "pete" <pf*****@mindspring.com> wrote in message
> news:40***********@mindspring.com...
> > The cast is the old way. No cast, is the new way.
>
> Four legs good, two legs bad.


Four legs animal. Two legs man.


Really? Remember the ancient riddle: what walks on four legs in
the morning, two legs in the afternoon, and three legs in the
evening?


A fish!

Few things are as simple as they at first appear.


This is certainly true of the whole malloc thing. I must admit I had no idea
that In The Beginning, malloc casts were not required. (That doesn't change
my opinion that it is unwise - in the main! - for C programmers to provide
the cast.)

--
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
Nov 14 '05 #104
xarax wrote:

"Default User" <fi********@boeing.com.invalid> wrote in message
news:40***************@boeing.com.invalid...

You shouldn't be using malloc() in C++ period. Writing code to move back
and forth like that is poor idea. C++ is its own language, and you
should be writing C++ code using the modern libraries. Don't write
cripple C code for C++ applications.


I interpreted his remark as *not* writing code
that compiles for both C and C++, but that he
doesn't have to change his *style* for either
language.

But you don't cast the result from new in C++, so the "style" is more
consistent not to do that for C either.

At any rate, substance over style says not to cast in C, because it can
hide defects in the code. It can't for C++.

Brian Rodenborn
Nov 14 '05 #105
Richard Heathfield wrote:
And I never said that he did. It is I who respect his reputation, not he who
insists on being respected.

That's a foreign concept to Mr. Tisdale, as he has never experienced
respect for his reputation.


Brian Rodenborn
Nov 14 '05 #106
"P.J. Plauger" wrote:
It's fine with me if you adopt this style, particularly having thought
it through. It's less fine that you and others absolutely refuse to
let in the possibility that well meaning people might arrive at a
different conclusion on such a delicate matter of style.

For many of use, the decision on correctness here comes from experience.
We see a LOT of newbie code, and a common error is to omit the inclusion
of stdlib.h and have that covered up with a cast. Sometimes the cast was
made deliberately to make the compiler shut up.

Now yes, the chances of that happening to an experienced programmer are
slim. Trollsdale will claim it's not a problem because his compiler
warns him about the missing include, and yes most compilers will or can
be set to issue such warnings, but we see the evidence. New programmer
DON'T have their compilers set. And they DO forget the include.

I'm of the opinion like many here that it's cleaner, it's more likely to
be correct, and who cares about C++ anyway? When I'm writing C++, I'll
worry about C++ish things. When I'm writing C, I'll worry about Cish
things.

There may be some people writing common source code libraries, but
that's not most of us, and such people aren't learning to program
anyway. They are also well plugged into the commonalities and
differences between the languages. That doesn't drive a general rule for
all C programmers.


Brian Rodenborn
Nov 14 '05 #107
j

"P.J. Plauger" <pj*@dinkumware.com> wrote in message
news:aC****************@nwrddc01.gnilink.net...
"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:40****************@news.individual.net...
"P.J. Plauger" <pj*@dinkumware.com> wrote:
If you write malloc calls without casts, it's not because it's
necessarily good programming practice but because your grandfather
did.
I would find it slightly insulting that an otherwise respectable
programmer like yourself would assume that I hadn't actually thought
about the matter, if it hadn't been you and this particular dispute.
Sorry, I was being cute at the cost of some precision. And I certainly
didn't intend to be insulting with that statement (or the rationale
that preceded it). My point was that you *can* write malloc calls
without casts only because the C committee gave them special
dispensation. We adopted a stronger typing system than in traditional
C with malice aforethought, but we didn't want to force the rewrite
of gazillions of lines of code that had been written without casts.
That would have been the result of adopting the tidier and more
consistent type-conversion rules of C++. We understood that malloc
calls were safer than average, because of the extra semantic
constraints imposed on the object pointers it returns; but we still
created a funny hole that's troublesome in other contexts, and we still
created a gratuitous difference between C and C++. Perhaps we should
have used some other notation in this context, instead of pirating
C++ notation and perverting it. But we did what we did.
As it is, I'll just state, flatly, that you're bloody wrong.


I have trouble feeling wrong when I'm trying to state a more
ecumenical position than damn near anybody else in this thread.


I don't think that you are, considering your original replies to both
Jack Klein and Mark McIntyre.

Or to be more succinct: "Nonsense! Bullshit!"
I _do_
avoid casts as much as possible, and I _do_ think that that is
necessarily good programming practice, and neither of my grandfathers
programmed, so I formed my own opinion on this.
It's fine with me if you adopt this style, particularly having thought
it through. It's less fine that you and others absolutely refuse to
let in the possibility that well meaning people might arrive at a
different conclusion on such a delicate matter of style.


1) Given that casts from malloc _are_ superfluous, why should one
cast?(References to languages other than ISO C are off-topic for this
newsgroup
e.g., ``I do so because I program in C++ at work, so I have adopted this
habit''
-- what you do at work is really irrelevant for this newsgroup, i.e., ERT's
original post)

2) Why should one cast from malloc when it might suppress a warning
which might otherwise be useful? (We all forget to include headers from
time to time)

I had a roommate in college whom I had known through most of high
school. He was a bright guy (got consistently better grades than
me) and we mostly got along. But early in our cohabitation, I
discovered that he put a toilet paper roll on the dispenser
backwards from the way I did. Now I had carefully thought through
the matter and worked out which was the right way. Yet this otherwise
intelligent guy had done the same exercise and came up with the
WRONG conclusion. We eventually worked out our differences without
bloodsheed.

The amusing thing about this story is that, for the past thirty
years, I have been unable to recall what MY original position was
or what OUR compromise became. And that lapse doesn't keep me
awake nights.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

Nov 14 '05 #108
In article <bv***********@ulysses.noc.ntua.gr>,
Papadopoulos Giannis <ip******@inf.uth.gr> wrote:
Richard Bos wrote:
d = malloc(50*sizeof(*d));
--------------------------
o the sortest way

Nope. Lose the parens around *d, then it's the shortest.


I like 'em.. I also do return(EXIT_SUCCESS); :)
d = malloc(50*sizeof(double));
------------------------------
o changing type of d is disastrous

Not for this single line, mind, but now imagine you have three dozen of
such lines in the program. You change a declaration, and all malloc()
calls. Except that you overlook one malloc()...


Implied...
(but aren't all pointers unsigned ints? - enlight me plz)

Certainly not. A pointer is a pointer, an integer is an integer. A
pointer to <foo> is an object suitable for containing the address of any
object of type <foo> - however the implementation chooses to implement
that address.
For example, in a debugging implementation, I can well imagine a pointer
consisting of the triplet <base memory block - start of object - size of
object>.


In the typical case I thought the pointer to be an int. I tried on win
and linux and managed to carry around a pointer in an int.

Unless, in other implementation a pointer is more than just an int..
Any more info??


64 bit Linux is getting quite popular.
Nov 14 '05 #109
Joona I Palaste wrote:
And I suppose you calculate the sum of an array this way?

int ar[(10)];
int i, sum=(0);
for ((i=(0)); ((i)<(10)); (i++)) {
(sum=((sum)+((ar)[(i)])));
}


Don't be so cynic... I do not think it is the same..

Nov 14 '05 #110
Richard Bos wrote:
Papadopoulos Giannis <ip******@inf.uth.gr> wrote:

Richard Bos wrote:
d = malloc(50*sizeof(*d));
--------------------------
o the sortest way

Nope. Lose the parens around *d, then it's the shortest.


I like 'em..

Hey, I'm not disputing your choice, only the denomination "shortest". If
you want to write ugly code, be my guest :-)


Ugly style or not, I got used to it and it is really difficult to adopt
a new style...

Anyone who does not like my code, has always the choice of a
beautifier... And I don't think it's all that bad...

Nov 14 '05 #111
Papadopoulos Giannis <ip******@inf.uth.gr> scribbled the following:
Joona I Palaste wrote:
And I suppose you calculate the sum of an array this way?

int ar[(10)];
int i, sum=(0);
for ((i=(0)); ((i)<(10)); (i++)) {
(sum=((sum)+((ar)[(i)])));
}
Don't be so cynic... I do not think it is the same..


Then *why* do you use parantheses in return statements? To make return
look like a function, so you can snigger when newbies think it really
*is* a function? =)

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"It sure is cool having money and chicks."
- Beavis and Butt-head
Nov 14 '05 #112
:::: If you write malloc calls without casts, it's not because it's
:::: necessarily good programming practice but because your grandfather did.

::: But this is the one place where you're an idiot. A complete one.

:: That's an 'Ad Hominen' argument

: So is Plauger's assertion that those of us who disagree with him do so
: out of mere tradition.

Let me get this strait.

"Your lack of cast on malloc is traditional,
not a superior programming technique"
and
"You are an idiot"

are considered equally ad hominem. Good to know, good to know.

In the meanwhile, perhaps it isn't too horrible to point out that
adding the cast is duplicated information, (which you might think
is bad, but) which means static checking can diagnose some problems
otherwise difficult to find, and often having to do with writing
past the end of the malloced region, which is Bad, which makes
the apparently bad duplication Good.

To a certain extent, it's a matter of style, but I find that
putting assertions and "redundant" casts in code makes it
significantly more likely to work if it compiles.
Therefore I find this a *useful* style.

But that's just me, and I must say I sympathize with stating
the same type twice (once for size (which is sometimes implicit),
once for typechecking) in the same malloc call.

On the Nth hand, something like

p = malloc(sizeof *p);

is particularly handy, because you can change the type of p
without having to dive into the code everywhere. Better (IMO)
would be something like

p = (typeof *p)malloc(sizeof *p);

but I don't think that works.
Wayne Throop th*****@sheol.org http://sheol.org/throopw
Nov 14 '05 #113
Wayne Throop <th*****@sheol.org> scribbled the following:

(snip discussion about Trollsdale and PJ Plauger)
In the meanwhile, perhaps it isn't too horrible to point out that
adding the cast is duplicated information, (which you might think
is bad, but) which means static checking can diagnose some problems
otherwise difficult to find, and often having to do with writing
past the end of the malloced region, which is Bad, which makes
the apparently bad duplication Good.
Yes, I agree, but the advantage of *not* casting is that the compiler
warns you about an incorrectly prototyped malloc(), which is a really
serious error, and one which no amount of casting anywhere can fix.
This, in my opinion, *far* outweighs any potential gain you might get
from the static checking you above describe. After all, if the returned
pointer is garbage right from the start, all bounds checking is
completely moot.
On the Nth hand, something like p = malloc(sizeof *p); is particularly handy, because you can change the type of p
without having to dive into the code everywhere. Better (IMO)
would be something like p = (typeof *p)malloc(sizeof *p); but I don't think that works.


No, that doesn't work, not in C anyway.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Remember: There are only three kinds of people - those who can count and those
who can't."
- Vampyra
Nov 14 '05 #114
P.J. Plauger wrote:
But early in our cohabitation, I
discovered that he put a toilet paper roll on the dispenser
backwards from the way I did. Now I had carefully thought through
the matter and worked out which was the right way.


You do realise that it's a function of whether the roll
is above or below your elbow, and not a universal constant,
don't you ?

--
pete
Nov 14 '05 #115

In article <8_********************@comcast.com>, "Mark Bruno" <ya*************@yahoo.com> writes:
Stroutstrup himself has said that all good-style C programs are also C++
programs, so it's just better style.
I am continually amazed at people who think Stroustrop (I assume this
is whom you meant) magically gets the last word in this argument. He
clearly has an interest in promoting C++, and that very likely
includes persuading C programmers to switch. What makes you think
he's an impartial observer? For that matter, what makes you think
he's right?

I have just invented a new language, called "C2", which is exactly
like C89 except that all identifiers must be at least 2 characters,
because I don't like single-character identifiers. All "good-style C
programs" are also C2 programs, which proves that 1) C2 is a "better
C", and 2) that avoiding single-character identifiers is "just better
style".

No, you say? Why is this argument valid for Stroustrop and not for
me?
Also, we're not limited to malloc()
here, what if you wrote your own function that returns a generic pointer.
What if I did? The same argument (against casting its return value)
would appear to apply.
Thirdly, it's always best to be explicit.
Why?
Lastly, it provides compatibility with older compilers.


I suspect a very small subset of C programmers need to write code
which is acceptable to both C89 and pre-C89 implementations, or
indeed write for pre-C89 implementations at all. Those who do may
indeed need to cast malloc. Their situation is not the common one,
nor the one we assume on this newsgroup, which is intended for the
discussion of standard C.

--
Michael Wojcik mi************@microfocus.com

What is it with this warm, quiet, nauseating bond between them?
-- Rumiko Takahashi, _Maison Ikkoku_, trans. Mari Morimoto, adapt. Gerard
Jones
Nov 14 '05 #116
Michael Wojcik <mw*****@newsguy.com> scribbled the following:
In article <8_********************@comcast.com>, "Mark Bruno" <ya*************@yahoo.com> writes:
Stroutstrup himself has said that all good-style C programs are also C++
programs, so it's just better style.
I am continually amazed at people who think Stroustrop (I assume this
is whom you meant) magically gets the last word in this argument. He
clearly has an interest in promoting C++, and that very likely
includes persuading C programmers to switch. What makes you think
he's an impartial observer? For that matter, what makes you think
he's right? I have just invented a new language, called "C2", which is exactly
like C89 except that all identifiers must be at least 2 characters,
because I don't like single-character identifiers. All "good-style C
programs" are also C2 programs, which proves that 1) C2 is a "better
C", and 2) that avoiding single-character identifiers is "just better
style". No, you say? Why is this argument valid for Stroustrop and not for
me?


You are right. Stroustrup's opinion matters on C++, and your opinion
matters on C2, but neither of your (neither's of you?) opinion matters
on C. C++ is Stroustrup's language and C2 is yours, fine, you can keep
them. Neither of you has claim over C.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"My absolute aspect is probably..."
- Mato Valtonen
Nov 14 '05 #117

In article <hq*****************@nwrddc01.gnilink.net>, "P.J. Plauger" <pj*@dinkumware.com> writes:
"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:sv********************************@4ax.com...
On Sat, 24 Jan 2004 19:00:24 GMT, in comp.lang.c , "P.J. Plauger"
<pj*@dinkumware.com> wrote:
"Jack Klein" <ja*******@spamcop.net> wrote in message
news:c2********************************@4ax.com.. .

> > warning: invalid conversion from `void*' to `double*'
>
> This is comp.lang.c, there is no such thing as an invalid conversion
> from void* to double*. The conversion is implicit and correct.

If the alignment is incorrect the conversion is invalid.


But its impossible for it to be incorrect. The C Standard says so. If
your h/w platform can't guarantee it, then you can't implement C
there.


Next step after nonsense -- bullshit. See 6.3.2.3, para. 7.


I suspect Mark thought you were claiming that a (non-null) void *
value *returned by malloc* could point to an area that was
incorrectly aligned for double. Of course a void * value obtained
another way (from the address of a pointer to a different type, or
from an uninitialized automatic void* variable, and so forth) may
point to such an area, and assigning such a value to a double* would
be invalid.

I also suspect Mark did not recognize your name, or he might have
double-checked before posting.

Of course, my suspicions may be ill-founded.

--
Michael Wojcik mi************@microfocus.com

Do not "test" parts, as this may compromise sensitive joinery. Those who
suffer difficulty should abandon the enterprise immediately. -- Chris Ware
Nov 14 '05 #118
pete wrote:
P.J. Plauger wrote:
But early in our cohabitation, I
discovered that he put a toilet paper roll on the dispenser
backwards from the way I did. Now I had carefully thought
through the matter and worked out which was the right way.


You do realise that it's a function of whether the roll
is above or below your elbow, and not a universal constant,
don't you ?


The universal solution, not approved by some style mavens, is to
remove the roll from the dispenser and leave it on the tank. :-)
This makes it fairly easy to perform the necessary allocations.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #119
In article <10********@sheol.org>, th*****@sheol.org (Wayne Throop)
wrote:
On the Nth hand, something like

p = malloc(sizeof *p);

is particularly handy, because you can change the type of p
without having to dive into the code everywhere. Better (IMO)
would be something like

p = (typeof *p)malloc(sizeof *p);

but I don't think that works.


If we go into things that are not C, then why not

allocate (p, 1);

with a new library function "allocate" which takes two arguments: An
lvalue p which must be a pointer to a complete type, and an integer. The
function would allocate space for as many objects as the integer
specifies and store the result in the pointer variable.

No chance to cast anything, so the whole argument would go away :-)

(Even better if this comes together with a reallocate function that
returns a boolean upon success; using realloc is always a pain. )
Nov 14 '05 #120
pete wrote:

P.J. Plauger wrote:
But early in our cohabitation, I
discovered that he put a toilet paper roll on the dispenser
backwards from the way I did. Now I had carefully thought through
the matter and worked out which was the right way.


You do realise that it's a function of whether the roll
is above or below your elbow, and not a universal constant,
don't you ?

If it's the kind with jokes printed on the roll, then it needs to come
over the top so it will be readable.


Brian Rodenborn
Nov 14 '05 #121
CBFalconer <cb********@yahoo.com> writes:
The universal solution, not approved by some style mavens, is to
remove the roll from the dispenser and leave it on the tank. :-)
This makes it fairly easy to perform the necessary allocations.


This also avoids a potential problem wherein the roll resists
turning, thereby leading to excessive fragmentation ;-)
Nov 14 '05 #122
Joona I Palaste wrote:
Then *why* do you use parantheses in return statements? To make return
look like a function, so you can snigger when newbies think it really
*is* a function? =)


Never thought of it... You are right... I started changing all my
sourcecode...

Nov 14 '05 #123
"j" <ja**********@bellsouth.net> wrote in message
news:Lp***************@bignews3.bellsouth.net...
1) Given that casts from malloc _are_ superfluous, why should one
cast?
Given that most whitespace _is_ superfluous, why should one use
whitespace?
(References to languages other than ISO C are off-topic for this
newsgroup
e.g., ``I do so because I program in C++ at work, so I have adopted this
habit''
-- what you do at work is really irrelevant for this newsgroup, i.e., ERT's original post)
Ever think of becoming a defense lawyer? You certainly like to stack the
deck against any answers you don't want to hear.

Actually, I've given more than one answer to this question, in this and
recent threads, that I believe meets your requirement of admissibility.
But I weary of repeating myself still more. All I'm holding out for,
and all I've asked for from the beginning, is for people to recognize
that:

1) Style rules should be developed by considering all applicable
principles and weighing their various importance *for that particular
rule*.

2) Well meaning people can have good reasons for giving different
weights and hence coming up with different style rules.
2) Why should one cast from malloc when it might suppress a warning
which might otherwise be useful? (We all forget to include headers from
time to time)


I've discussed this before, with my personal weights, too.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Nov 14 '05 #124
On Mon, 26 Jan 2004 00:29:24 GMT, in comp.lang.c , "P.J. Plauger"
<pj*@dinkumware.com> wrote:
What I find interesting about this debate is the two positions being
espoused:
Correct. But not these two. The two positions are

1) putting in malloc casts is perfectly ok, its harmless.
2) putting in malloc casts is unnecessary and therefore not ok.

1) Omitting casts on malloc calls is acceptable, but not necessarily
virtuous.

2) Putting casts on malloc calls is stupid.
If you were in either camp, I'd rescind my remark faster than a very
fast thing on roller skates, being towed by a jag.
Those of us in the first camp are going to keep using casts,
But you're not in that camp. Youre in the "casting malloc is a good
thing" camp, as your own postings both in this thread and elsewhere
have showed.
and we're
going to keep respecting those who don't. It would be nice if we were
granted a bit of respect in turn, but what the hell.
As I said, I respect you enormously. You mistake intolerance of your
one stupidity for lack of respect
A closed mind avoids the risk of having to change.


I'd not know, I don't have one.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #125
On Mon, 26 Jan 2004 11:20:58 +0200, in comp.lang.c , Papadopoulos
Giannis <ip******@inf.uth.gr> wrote:
E. Robert Tisdale wrote:
(but aren't all pointers unsigned ints? - enlight me plz)

No.


So???


So don't assume they are, or your programme will crash.
double* d = (double*)malloc(50*sizeof(double));


I think I wrote it first :)


I suspect that D Ritchie has that honour :-)
- though, without the leading double* which
is implied indeed...


At the risk of concealing a missed header, and making the code hard to
read. IMHO, YMMV.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #126
On Mon, 26 Jan 2004 14:23:28 GMT, in comp.lang.c , "P.J. Plauger"
<pj*@dinkumware.com> wrote:
Not in that sentence. It's a bald statement that happens to be untrue.
Now, had he said "there is no such thing aa an invalid conversion from
malloc(sizeof(double) to double*" I'd be quick to agree. But he didn't.
And precision is everything in our business.


IF you'd been following the context, it would have been abundantly
clear. But I guess we all snipped too much context.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #127
On Mon, 26 Jan 2004 22:54:26 GMT, in comp.lang.c , "P.J. Plauger"
<pj*@dinkumware.com> wrote:
"j" <ja**********@bellsouth.net> wrote in message
news:Lp***************@bignews3.bellsouth.net.. .
1) Given that casts from malloc _are_ superfluous, why should one
cast?
Given that most whitespace _is_ superfluous, why should one use
whitespace?


Igenerallydon'twhenitdoesn'tmatter-haveyoueverseenwebbytheway?

Joking aside, you're actually reinforcing one of the arguments against
casting. One should write for readability. Whitespace (used
approriately) improves that. Casts (used appropriately) improve that.
Casts stuck in where unnecessary do not improve that.
Ever think of becoming a defense lawyer? You certainly like to stack the
deck against any answers you don't want to hear.


This statement has a fine legal name, which escapes me for the moment.
Its something to do with trying to divert attention off the actual
point, because you don't have a rebuttal.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #128
On Mon, 26 Jan 2004 15:04:25 +0000, in comp.lang.c , Richard
Heathfield <in*****@address.co.uk.invalid> wrote:
E. Robert Tisdale wrote:
Richard Heathfield wrote:
If you're wise, Mark, you'll retract that.
Mr. Plauger's statement, quoted above, is IMHO erroneous
but I don't think it's legitimate to call him an idiot.
inexplicably, I didn't see your original post. Did ERT answer it
immediately? My reader has a "fry all tisdaleposts" setitng.

Anyway to respond to you now, sorry, but I won't retract. I've read
through his reasoning several times, and its IMHO wrong. Since he
persists in holding a wrong position, I consider him idiotic on this
point.
Note that this isn't a general position, merely on the malloc point.
He has already stated for the benefit of this newsgroup that
(what I consider to be) his unusual circumstances
make it sensible for him to make his code capable
of being compiled under both C and C++; given his reputation,


We've been over it many many times, and while I appreciate his work
circumstances make it much more convenient for him to cast malloc,
thats not a valid reason for advocating it to C programmers.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #129
On 26 Jan 2004 21:11:41 GMT, in comp.lang.c , mw*****@newsguy.com
(Michael Wojcik) wrote:
I suspect Mark thought you were claiming that a (non-null) void *
value *returned by malloc* could point to an area that was
incorrectly aligned for double.
Yes, since this was the topic under discussion !
I also suspect Mark did not recognize your name, or he might have
double-checked before posting
I recognised it very well indeed, and I elected to post anyway,
because I believe that when it comes to malloc casts, PJ has the
programming equivalent of a crush on a beautiful but unsuitable woman,
and is unable to see that she's stealing his money, sleeping with his
friends and using his house to sell dope from.... :-)
Of course, my suspicions may be ill-founded.


Nope!

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #130
On Mon, 26 Jan 2004 21:55:49 GMT, in comp.lang.c , Default User
<fi********@boeing.com.invalid> wrote:
pete wrote:

You do realise that it's a function of whether the roll
is above or below your elbow, and not a universal constant,
don't you ?


If it's the kind with jokes printed on the roll, then it needs to come
over the top so it will be readable.


Depends what position you adopt when using the facilities....
=:-0

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #131
"P.J. Plauger" wrote:

"j" <ja**********@bellsouth.net> wrote in message
news:Lp***************@bignews3.bellsouth.net...
1) Given that casts from malloc _are_ superfluous, why should one
cast?


Given that most whitespace _is_ superfluous, why should one use
whitespace?

How are casts from malloc() superfluous? Code should work identically
whether the casts are there or not. However, code that uses casts is
different from that which does not in cases of failure to properly
declare malloc(). In that case they convert a int into a pointer.

Brian Rodenborn
Nov 14 '05 #132
"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:mi********************************@4ax.com...
On Mon, 26 Jan 2004 00:29:24 GMT, in comp.lang.c , "P.J. Plauger"
<pj*@dinkumware.com> wrote:
What I find interesting about this debate is the two positions being
espoused:


Correct. But not these two. The two positions are

1) putting in malloc casts is perfectly ok, its harmless.
2) putting in malloc casts is unnecessary and therefore not ok.


I'm beginning to understand the communication problem here.
I've never espoused either of these posiitons, but that seems
to be what you've read.
Those of us in the first camp are going to keep using casts,


But you're not in that camp. Youre in the "casting malloc is a good
thing" camp, as your own postings both in this thread and elsewhere
have showed.


Not to me.
and we're
going to keep respecting those who don't. It would be nice if we were
granted a bit of respect in turn, but what the hell.


As I said, I respect you enormously. You mistake intolerance of your
one stupidity for lack of respect


Uh yes, I *do* consider intolerance a lack of respect. Fortunately for
me, I don't really give a rat's ass whether you respect me or not.
I've been staying in this discussion for a variety of tutorial
purposes (which IMO I've been achieving).
A closed mind avoids the risk of having to change.


I'd not know, I don't have one.


And yet you can be intolerant. An interesting pair of positions
to reconcile.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Nov 14 '05 #133
"Default User" <fi********@boeing.com.invalid> wrote in message
news:40***************@boeing.com.invalid...
"P.J. Plauger" wrote:

"j" <ja**********@bellsouth.net> wrote in message
news:Lp***************@bignews3.bellsouth.net...
1) Given that casts from malloc _are_ superfluous, why should one
cast?
Given that most whitespace _is_ superfluous, why should one use
whitespace?

How are casts from malloc() superfluous? Code should work identically
whether the casts are there or not.


I personally never said that casts from malloc() are superfluous,
just whitespace. And how code "should work" is just one factor to
consider in developing style rules.
However, code that uses casts is
different from that which does not in cases of failure to properly
declare malloc(). In that case they convert a int into a pointer.


Right. And other failures are caught when casts *are* present that
are obscured when they're omitted. It's a tradeoff, a matter of
choosing relative weights. Once you decide that any one weight is
a binary choice between okay and idiocy, you may as well divide
through by zero.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Nov 14 '05 #134
"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:eb********************************@4ax.com...
On Mon, 26 Jan 2004 22:54:26 GMT, in comp.lang.c , "P.J. Plauger"
<pj*@dinkumware.com> wrote:
"j" <ja**********@bellsouth.net> wrote in message
news:Lp***************@bignews3.bellsouth.net.. .
1) Given that casts from malloc _are_ superfluous, why should one
cast?


Given that most whitespace _is_ superfluous, why should one use
whitespace?


Igenerallydon'twhenitdoesn'tmatter-haveyoueverseenwebbytheway?

Joking aside, you're actually reinforcing one of the arguments against
casting. One should write for readability. Whitespace (used
approriately) improves that. Casts (used appropriately) improve that.
Casts stuck in where unnecessary do not improve that.


Again you're applying one set of weights and value judgements with
nary a thought that other weights might be valid in other contexts.
Ever think of becoming a defense lawyer? You certainly like to stack the
deck against any answers you don't want to hear.


This statement has a fine legal name, which escapes me for the moment.
Its something to do with trying to divert attention off the actual
point, because you don't have a rebuttal.


Well, maybe. Had I stopped there, you might have a legitimate gripe.
But the part you snipped went on to discuss the various answers I've
given.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Nov 14 '05 #135
"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:qs********************************@4ax.com...
On 26 Jan 2004 21:11:41 GMT, in comp.lang.c , mw*****@newsguy.com
(Michael Wojcik) wrote:
I suspect Mark thought you were claiming that a (non-null) void *
value *returned by malloc* could point to an area that was
incorrectly aligned for double.


Yes, since this was the topic under discussion !
I also suspect Mark did not recognize your name, or he might have
double-checked before posting


I recognised it very well indeed, and I elected to post anyway,
because I believe that when it comes to malloc casts, PJ has the
programming equivalent of a crush on a beautiful but unsuitable woman,
and is unable to see that she's stealing his money, sleeping with his
friends and using his house to sell dope from.... :-)


Now you're simply being a jerk. From your earlier posting:

: This statement has a fine legal name, which escapes me for the moment.
: Its something to do with trying to divert attention off the actual
: point, because you don't have a rebuttal.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


Nov 14 '05 #136
"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:dl********************************@4ax.com...
Anyway to respond to you now, sorry, but I won't retract. I've read
through his reasoning several times, and its IMHO wrong. Since he
persists in holding a wrong position, I consider him idiotic on this
point.
Note that this isn't a general position, merely on the malloc point.


I've now accumulated enough evidence that you're incapable of
reading accurately what others write, particularly when you don't
agree with them. It is no longer amusing that you keep calling
my position idiotic; now it is merely sad. My part of this discussion
is nearing its end. (And you accuse others of trolling...)
He has already stated for the benefit of this newsgroup that
(what I consider to be) his unusual circumstances
make it sensible for him to make his code capable
of being compiled under both C and C++; given his reputation,


We've been over it many many times, and while I appreciate his work
circumstances make it much more convenient for him to cast malloc,
thats not a valid reason for advocating it to C programmers.


And you haven't even noticed that I'm *not* advocating this
position to C programmers in general. I've merely been defending
why it might sometimes be a reasonable position for some C
programmers in some contexts. The only thing I really can't stand
is intolerance. But you can only push that button of mine so many
times before I learn to tune it out.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Nov 14 '05 #137
Christian Bau wrote:
If we go into things that are not C, then why not

allocate (p, 1);

with a new library function "allocate" which takes two arguments: An
lvalue p which must be a pointer to a complete type, and an integer. The
function would allocate space for as many objects as the integer
specifies and store the result in the pointer variable.

No chance to cast anything, so the whole argument would go away :-)


No. Pointer p could never be a constant.

Nov 14 '05 #138
E. Robert Tisdale wrote:
Christian Bau wrote:
If we go into things that are not C, then why not

allocate (p, 1);

with a new library function "allocate" which takes two arguments: An
lvalue p which must be a pointer to a complete type, and an integer. The
function would allocate space for as many objects as the integer
specifies and store the result in the pointer variable.

No chance to cast anything, so the whole argument would go away :-)


No. Pointer p could never be a constant.


With one exception, each word on the first line of Christian's reply is
monosyllabic. How on /earth/ did you manage to misunderstand 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
Nov 14 '05 #139
Mark A. Odell wrote:
Sidney Cadot <si****@jigsaw.nl> wrote in
news:bu**********@news.tudelft.nl:

If the FAQ is to properly reflect the CLC opinion, it should at least
mention the counter-argument that failing to cast malloc prevents a C++
compiler from having a fighting chance at compiling your code.
Why would a C++ compiler need to worry about malloc()'ing code?
To be compliant with the relevant standard, ISO 14882.
They have memory allocation schemes of their own in C++.
So they do, but in addition, malloc(), free(), and friends are also
supported, with semantics that are pretty close to C semantics. No
points for guessing why that is.
All my loop indexes are called 'new' just to prevent accidental
C++ compilation C code (okay, not really).
I fail to see your point.
At least, the presentation of the issue would then be honest. Right now,
it is an over-simplification of a complicated issue where there are
really two sides, I think.

No, two languages. One that has malloc() and does not require a cast and a
language that cannot prohibit the use of the former's memory allocation
function but that does require a cast.


Let me get this straight: do you deny there are to sides to this issue?
This seems to be somewhat implied by the "No".

Yours may well be bigger than mine, but surely, there /are/ two sides.

With Mr. Plauger, I am amazed by the complete inability demonstrated by
many of the 'anti-cast' crowd to admit even a hint of nuance in their
thought process on this issue. Being 'pro-cast' myself, I see perfectly
well the limitations of my view and see the good sense in some of the
arguments of those I disagree with. In fact, when commenting on code
that does malloc casting here in c.l.c., I have repeatedly pointed out
that malloc casting is generally not considered good style by most
regulars. A minimal amount of reciprocity would be welcome.

Best regards,

Sidney

Nov 14 '05 #140
"Mark A. Odell" <no****@embeddedfw.com> wrote:
I always use the explicit cast
to prevent my C++ compiler from complaining about


You *shouldn't* use malloc in C++!


Why not? What if you wish to explictely make sure constructors are
not invoked for all entries? I don't think "new" has an option where
you can turn this off.
The important thing here is to adopt a style and stick to it.


True but this is not a style issue.


No, its a language weakness issue. One of the few good things to come
out of the C99 spec is the adoption of C++'s requirement for
prototype, and not assuming the default: int ()(int) . But since the
OP in highly unlikely to have practical access to a C99 compiler
within the next 5 years, the simpler solution is simply to compile
with C++ (after making your code C++ safe, of course) to catch these
and other kinds of errors.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
Nov 14 '05 #141
On 26 Jan 2004 21:23:19 GMT
Joona I Palaste <pa*****@cc.helsinki.fi> wrote:
You are right. Stroustrup's opinion matters on C++, and your opinion
matters on C2, but neither of your (neither's of you?) opinion matters
on C. C++ is Stroustrup's language and C2 is yours, fine, you can keep
them. Neither of you has claim over C.


I believe it's "neither of your opinions".

--
donLouis
Nov 14 '05 #142
Papadopoulos Giannis <ip******@inf.uth.gr> wrote:
I've read nearly completely the whole thread, although in the way I
lost my path.

I assume the following:

d = malloc(50*sizeof(*d));
--------------------------
o the sortest way
They all generate equivalent object code (when they are correct, and
as intended.)
o the most portable
Its not portable to anal C++ compilers set at their most pedantic
warning level.
o does remember you to include stdlib
Or malloc.h on some systems. However if you use a C++ (or C99)
compiler to compile your C code, you'll get the lack of prototype as
an error whether you cast or not.
o changing type of d does not affect anything
That is about its only real advantage.
d = (double*)malloc( 50*sizeof(double) );
-----------------------------------------
o does not want stdlib (but aren't all pointers unsigned ints? - enlight
me plz)
On AMD64 (aka x86-64) pointers have long long (or __int64)
representation. On 16bit DOS systems pointers can have a kind of
int[2] representation. In general pointers should not be assumed to
be of size int on code which is supposed to be portable.
o it gives a good hint on what d's type is


Actually the declaration of d is the only credible source of what type
d is.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
Nov 14 '05 #143
Sidney Cadot wrote:
With Mr. Plauger, I am amazed by the complete inability demonstrated by
many of the 'anti-cast' crowd to admit even a hint of nuance in their
thought process on this issue. Being 'pro-cast' myself...


As I see it, as a member of the 'anti-cast' crowd, the problem is
with the very notion of a 'pro-cast' position (a la Tisdale). We
see no possible rationale for this in terms of the C programming
language.

On the other hand, P.J. Plauger's basic position seems perfectly
reasonable, namely that there are some special contexts where a
body of code has to be compiled indifferently as C or as C++, and
in those special contexts casting the return from malloc is
required (and does no harm if we can assume that the coder is
astute enough to ensure that <stdlib.h> is always #included).

This, it seems to me, is not a 'pro-cast' position: it's just
saying that real-world considerations other than "good C
programming" sometimes dictate a cast. Fair enough.

--
Allin Cottrell
Department of Economics
Wake Forest University, NC
Nov 14 '05 #144
Paul Hsieh wrote:
Papadopoulos Giannis <ip******@inf.uth.gr> wrote:
o does remember you to include stdlib
Or malloc.h on some systems.


<stdlib.h> is always correct for malloc.
<malloc.h> is rarely correct for malloc.
However if you use a C++ (or C99)
compiler to compile your C code, you'll get the lack of prototype as
an error whether you cast or not.


On C90 compilers, however, you won't; and C90 compilers are still the most
widely-used C compilers.
o changing type of d does not affect anything


That is about its only real advantage.


You forgot the other advantages to omitting the cast:

1) doesn't add pointless, unnecessary code;
2) doesn't suppress an important required diagnostic;
3) gives you a heads-up if you accidentally compile your C code with a
compiler for some other language with notionally similar syntax but
different semantics.
o it gives a good hint on what d's type is


Actually the declaration of d is the only credible source of what type
d is.


That's certainly true.

--
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
Nov 14 '05 #145
In article <40**************@jpl.nasa.gov>,
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote:
Christian Bau wrote:
If we go into things that are not C, then why not

allocate (p, 1);

with a new library function "allocate" which takes two arguments: An
lvalue p which must be a pointer to a complete type, and an integer. The
function would allocate space for as many objects as the integer
specifies and store the result in the pointer variable.

No chance to cast anything, so the whole argument would go away :-)


No. Pointer p could never be a constant.


Go away, idiot.
Nov 14 '05 #146
th*****@sheol.org (Wayne Throop) wrote:

[ Please do not remove attribution lines. ]
:::: If you write malloc calls without casts, it's not because it's
:::: necessarily good programming practice but because your grandfather did.

::: But this is the one place where you're an idiot. A complete one.

:: That's an 'Ad Hominen' argument

: So is Plauger's assertion that those of us who disagree with him do so
: out of mere tradition.

Let me get this strait.

"Your lack of cast on malloc is traditional,
not a superior programming technique"
and
"You are an idiot"

are considered equally ad hominem.
Yes. "You do not think when you don't cast malloc()" and "you do not
think when you do cast malloc()" are equally ad hominem.
After all, Mark didn't call Plauger an idiot per se, as you make him out
to have done; he quite specifically claimed that _this_ matter is the
only one where he considers him so.
On the Nth hand, something like

p = malloc(sizeof *p);

is particularly handy, because you can change the type of p
without having to dive into the code everywhere. Better (IMO)
would be something like

p = (typeof *p)malloc(sizeof *p);

but I don't think that works.


It doesn't work in C (though it might in Gnuck), it is probably wrong
anyway (shouldn't that be typeof p?), but most importantly: in what way
does it give you any more information at all than the first line? I see
absolutely no advantage to it whatsoever.

Richard
Nov 14 '05 #147
Richard Bos <rl*@hoekstra-uitgeverij.nl> scribbled the following:
th*****@sheol.org (Wayne Throop) wrote:
Better (IMO)
would be something like

p = (typeof *p)malloc(sizeof *p);

but I don't think that works.
It doesn't work in C (though it might in Gnuck), it is probably wrong
anyway (shouldn't that be typeof p?), but most importantly: in what way
does it give you any more information at all than the first line? I see
absolutely no advantage to it whatsoever.


Well, it does have the advantage that if the type of p is ever changed,
then the compiler will... oh, sod that.
Well, it does have the advantage that if malloc() is incorrectly
prototyped, its return value will be... oh, sod that.
Well, it does have the advantage that it makes the code valid C++...
except C++ doesn't have a "typeof" operator.
Well, at least it does have the advantage of keeping people like
Trollsdale and PJ Plauger happy when they see that the cast is in
there. =)

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"It sure is cool having money and chicks."
- Beavis and Butt-head
Nov 14 '05 #148
Default User <fi********@boeing.com.invalid> wrote:
"P.J. Plauger" wrote:

"j" <ja**********@bellsouth.net> wrote in message
news:Lp***************@bignews3.bellsouth.net...
1) Given that casts from malloc _are_ superfluous, why should one
cast?
Given that most whitespace _is_ superfluous, why should one use
whitespace?


How are casts from malloc() superfluous? Code should work identically
whether the casts are there or not.


Yes. Which is why they're superfluous.
However, code that uses casts is
different from that which does not in cases of failure to properly
declare malloc(). In that case they convert a int into a pointer.


Erm... no. They convert something the programmer _thinks_ is a pointer,
but has implicitly _declared_ to be an int, and which may not actually
exist or have a valid value, into a pointer. Without so much as a
warning.

Richard
Nov 14 '05 #149
"P.J. Plauger" <pj*@dinkumware.com> wrote:
"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:40****************@news.individual.net...
"P.J. Plauger" <pj*@dinkumware.com> wrote:
"Jack Klein" <ja*******@spamcop.net> wrote in message
news:c2********************************@4ax.com...

> > warning: invalid conversion from `void*' to `double*'
>
> This is comp.lang.c, there is no such thing as an invalid conversion
> from void* to double*. The conversion is implicit and correct.

Nonsense. If the alignment is incorrect the conversion is invalid.


We're talking about a malloc() call here. The pointer is required to be
correctly aligned.


Not in that sentence. It's a bald statement that happens to be untrue.
Now, had he said "there is no such thing aa an invalid conversion from
malloc(sizeof(double) to double*" I'd be quick to agree. But he didn't.


I'd agree with that if the line containing the malloc() call wasn't
still present and visible in the post in question.

Richard
Nov 14 '05 #150

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

33
by: hermit_crab67 | last post by:
Can someone explain to a C newbie why this doesn't work as I expect it to work? (expectations clearly outlined in the printf statement in main routine) OS: Linux 2.4.26 GCC: 2.95.4 void...
35
by: ytrama | last post by:
Hi, I have read in one of old posting that don't cast of pointer which is returned by the malloc. I would like to know the reason. Thanks in advance, YTR
32
by: alex.j.k2 | last post by:
Hello all, I have "PRECISION" defined in the preprocessor code and it could be int, float or double, but I do not know in the code what it is. Now if I want to assign zero to a "PRECISION"...
101
by: Tinkertim | last post by:
Hi, I have often wondered if casting the return value of malloc() (or friends) actually helps anything, recent threads here suggest that it does not .. so I hope to find out. For instance : ...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.