I recently read an article containing numerous gripes about common C
practices. One of them contained a gripe about the use of the sizeof
operator as an argument to malloc calls. The supposed "right" way to go
about calling malloc instead is to dereference a pointer; apparently even
if said pointer is undefined.
E.g.
ptr = malloc(sizeof(struct some_struct)); = wrong
ptr = malloc(*ptr); = right
The method works on my platform, but doesn't really sit right with me. Is
the code portable? Standard? I've been looking myself, but haven't come
across anything forbidding it as of yet.
Aug 25 '08
98  6324 
Richard Heathfield wrote:
pete said:
>Richard Heathfield wrote:
<snip>
>>What have I missed?
You missed the part of the thread that had been snipped,
You're right. That's precisely what I missed.
>in which
Peter Nilsson wrote:
ptr = (struct some_struct *) malloc(sizeof *ptr);
and Keith Thompson asked:
How is the cast helpful?
and Peter Nilsson replied:
If the pointer types are not compatible,
then a diagnostic is required. [Sound familiar?]
because Peter Nilsson didn't know what he was talking about.
Um, perhaps so. But might he not have meant that, if ptr is of some type
that is not void * and also is not struct some_struct *, a diagnostic
message would be required, and that he considers this beneficial? It would
be a sort of compile-time assertion that ptr has type struct some_struct
*, yes? I don't say I agree with that by any means (and in fact I don't
think I'm telling you anything new when I say that I consider the castless
version is better style and more robust), but it seems to me that it
needn't necessarily be ignorance or trolling that led him to that
conclusion. It might just be an alternative point of view, and it seems to
me that it's a defensible one, although I don't happen to agree with it
myself.
If ptr is supposed to be (struct some_struct *) and it isn't,
then the problem will show up later in the code when ptr
is being used where a (struct some_struct *) is supposed to be,
and a warning will be generated there.
--
pete
Martin Ambuhl wrote:
Peter Nilsson wrote:
>Martin Ambuhl <mamb...@earthlink.netwrote:
>>Peter Nilsson wrote:
<snip>
malloc returns a void *. There is no pointer type not
compatible with it. Sound familiar? Get a clue.
It sounds like a lie that's been repeated so often it's
got the status of fact.
The only compatible type to void * is void *.
Having proven your ignorance and your trolldom, you may now enter my
killfile.
Um, er, Martin: Section 6.2.7 agrees with him ...
--
Eric Sosman es*****@ieee-dot-org.invalid
Peter Nilsson <ai***@acay.com.auwrote:
<http://www-db-out.research.bell-labs.com/cm/cs/cbook/2ediffs.html>
Quote:
142(S6.5, toward the end): The remark about casting the
return value of malloc ("the proper method is to declare
... then explicitly coerce") needs to be rewritten. The
example is correct and works, but the advice is debatable
in the context of the 1988-1989 ANSI/ISO standards. It's
not necessary (given that coercion of void * to
ALMOSTANYTYPE * is automatic), and possibly harmful if
malloc, or a proxy for it, fails to be declared as
returning void *. The explicit cast can cover up an
unintended error. On the other hand, pre-ANSI, the cast
was necessary, and it is in C++ also.
It's surprising how some people seem to have interpreted
"The example is correct and works" as somehow meaning the
example is incorrect and doesn't.
Not quite as surprising as the number of people who read "needs to be
rewritten" as "is more than correct and should be followed by
everybody".
Richard rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
Peter Nilsson <ai***@acay.com.auwrote:
><http://www-db-out.research.bell-labs.com/cm/cs/cbook/2ediffs.html>
Quote:
142(S6.5, toward the end): The remark about casting the
return value of malloc ("the proper method is to declare
... then explicitly coerce") needs to be rewritten. The
example is correct and works, but the advice is debatable
in the context of the 1988-1989 ANSI/ISO standards. It's
not necessary (given that coercion of void * to
ALMOSTANYTYPE * is automatic), and possibly harmful if
malloc, or a proxy for it, fails to be declared as
returning void *. The explicit cast can cover up an
unintended error. On the other hand, pre-ANSI, the cast
was necessary, and it is in C++ also.
It's surprising how some people seem to have interpreted
"The example is correct and works" as somehow meaning the
example is incorrect and doesn't.
Not quite as surprising as the number of people who read "needs to be
rewritten" as "is more than correct and should be followed by
everybody".
Richard
What is more surprising is how many people here tell fibs to enhance
their clique status as Hathfield wannabes. The old "I have never seen
that" remarks seen so often are simply lies from anyone who has worked
in industry because so much code is NOT Ansi C. As for the potential for
error from putting the cast in. since the implementation provides the
malloc in 99.9999999999999999999999999999% of instances there really is
not issue since it will be correctly prototyped.
pete <pf*****@mindspring.comwrites:
Richard Heathfield wrote:
>pete said:
>>Richard Heathfield wrote:
<snip>
>>>What have I missed?
You missed the part of the thread that had been snipped,
You're right. That's precisely what I missed.
>>in which
Peter Nilsson wrote:
ptr = (struct some_struct *) malloc(sizeof *ptr);
and Keith Thompson asked:
How is the cast helpful?
and Peter Nilsson replied:
If the pointer types are not compatible,
then a diagnostic is required. [Sound familiar?]
You apparently missed my later followup in which I acknowledged that
he had a reasonable argument in favor of casting the result of malloc.
I don't consider it a convincing argument, but it's a reasonable one.
>>because Peter Nilsson didn't know what he was talking about.
Um, perhaps so. But might he not have meant that, if ptr is of some
type that is not void * and also is not struct some_struct *, a
diagnostic message would be required, and that he considers this
beneficial? It would be a sort of compile-time assertion that ptr
has type struct some_struct *, yes? I don't say I agree with that by
any means (and in fact I don't think I'm telling you anything new
when I say that I consider the castless version is better style and
more robust), but it seems to me that it needn't necessarily be
ignorance or trolling that led him to that conclusion. It might just
be an alternative point of view, and it seems to me that it's a
defensible one, although I don't happen to agree with it myself.
If ptr is supposed to be (struct some_struct *) and it isn't,
then the problem will show up later in the code when ptr
is being used where a (struct some_struct *) is supposed to be,
and a warning will be generated there.
Catching errors as early as possible is almost always a good thing.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
In article <g9**********@registered.motzarella.org>,
Richard <rg****@gmail.comwrote:
>As for the potential for
error from putting the cast in. since the implementation provides the
malloc in 99.9999999999999999999999999999% of instances there really is
not issue since it will be correctly prototyped.
Surely the case that motivates this is the one where the user doesn't
include a header that declares malloc(), so that the cast suppresses
the "assignment from integer to pointer" error.
Certainly many old program did this and only worked because the
int/pointer conversion was a no-op.
-- Richard
--
Please remember to mention me / in tapes you leave behind.
Richard Heathfield wrote:
Martin Ambuhl said:
>Peter Nilsson wrote:
>>Martin Ambuhl <mamb...@earthlink.netwrote:
Peter Nilsson wrote:
<snip>
malloc returns a void *. There is no pointer type not
compatible with it. Sound familiar? Get a clue.
It sounds like a lie that's been repeated so often it's
got the status of fact.
The only compatible type to void * is void *.
Having proven your ignorance and your trolldom, you may now enter my
killfile.
My curiosity has overcome my reluctance to display my own ignorance. I have
read through the Standard, looking for information about the compatibility
of void * with other types, and I can't find any. I *did* find the bit
about it being okay to convert any object pointer or incomplete pointer to
void * and back without loss of information - which sure *sounds* like
compatibility - but the Standard does not explicitly state that it *is*
compatibility.
What have I missed?
You missed the context, in which Peter Nilsson made the bogus claim was
that casting the return from malloc was a good idea because of a
(completely irrelevant) supposed pointer incompatibility problem.
You missed the line in which Peter Nilsson claimed that anyone who knew
more than he did was lying.
And you missed his claim above that
>>The only compatible type to void * is void *.
Since compatible pointer types are, strictly, defined in terms of
compatibility of the objects they point to, void * is not compatible
with _anything_, not even void *. But, luckily, the standard itself
gives examples of common types of void * and other pointer types, which
common types exist only for compatible types. This should be a clue
that "pointer incompatibility" in the strict sense is not relevant, and
Peter Nilsson is certainly ignorant as well as a troll.
Martin Ambuhl wrote:
Richard Heathfield wrote:
Martin Ambuhl said:
Peter Nilsson wrote:
....
>The only compatible type to void * is void *.
....
Since compatible pointer types are, strictly, defined in terms of
compatibility of the objects they point to, void * is not compatible
with _anything_, not even void *.
6.2.7p1 always applies: "Two types have compatible type if their types
are the same."
... But, luckily, the standard itself
gives examples of common types of void * and other pointer types, which
common types exist only for compatible types.
The standard uses the term "common type" only in 6.5.15p7, and without
bothering to define the term. The special handling specified by that
clause for void* pointers applies only if the two pointer types are
NOT compatible; otherwise the composite type is used.
... This should be a clue
that "pointer incompatibility" in the strict sense is not relevant,
Yes, the fact that void* isn't compatible with any other type except
void* is irrelevant; but it is also true.
On Thu, 28 Aug 2008 19:57:44 +0000, Herbert Rosenau wrote:
Casting the result of malloc is an error!
No, it isn't. Relying on an implicit function declaration of malloc is an
error. Casting its result may hide that error, but that doesn't make the
cast the problem.
It will suppress any
diagnostic too.
Leeav off any casting will giv you a diagnostic when you have failed to
#include <stdlib.has you should to get the correct prototype of malloc
in sight.
C99 requires a diagnostic when an undeclared function is called, and C90
implementations commonly at least have an option to warn for this as well.
Leaving off the cast will not necessarily give you any more diagnostics
than including it.
On Thu, 28 Aug 2008 14:04:21 -0700, jameskuyper wrote:
If malloc() is called without #include <stdlib.hand without
any conflicting user-provided declaration of malloc() as an identfier
without external linkage, in C90 it would be interpreted as an
identifier with external linkage. It should be trivial for the compiler
to notice that this identifier matches the spelling of a standard
library identifier, but does not match the actual definition of that
identifier, in which case it is permitted to issue a diagnostic. I don't
know if any compiler actually does this.
$ cat example.c
main() {
free(malloc(20));
return zero();
}
zero() {
return 0;
}
$ gcc -std=c89 -pedantic -c example.c
example.c: In function ‘main’:
example.c:2: warning: incompatible implicit declaration of built-in
function ‘free’
example.c:2: warning: incompatible implicit declaration of built-in
function ‘malloc’
No warning is generated (by default) for the implicit declaration of
function zero, but the implicit declarations of functions free and malloc
do get diagnosed.
Martin Ambuhl <ma*****@earthlink.netwrites:
Richard Heathfield wrote:
>Martin Ambuhl said:
>>Peter Nilsson wrote:
Martin Ambuhl <mamb...@earthlink.netwrote:
Peter Nilsson wrote:
><snip>
malloc returns a void *. There is no pointer type not
compatible with it. Sound familiar? Get a clue.
It sounds like a lie that's been repeated so often it's
got the status of fact.
The only compatible type to void * is void *.
Having proven your ignorance and your trolldom, you may now enter my
killfile.
My curiosity has overcome my reluctance to display my own
ignorance. I have read through the Standard, looking for information
about the compatibility of void * with other types, and I can't find
any. I *did* find the bit about it being okay to convert any object
pointer or incomplete pointer to void * and back without loss of
information - which sure *sounds* like compatibility - but the
Standard does not explicitly state that it *is* compatibility.
What have I missed?
You missed the context, in which Peter Nilsson made the bogus claim
was that casting the return from malloc was a good idea because of a
(completely irrelevant) supposed pointer incompatibility problem.
I didn't find his claim bogus; I found it quite interesting, though I
still don't agree with it. YMMV.
You missed the line in which Peter Nilsson claimed that anyone who
knew more than he did was lying.
I missed that line as well. He did use the word "lie", but there was
no implication that he was applying it to "anyone who knew more than
he did". I quoted it above; you can see for yourself. I suppose
you're deliberately exaggerating, but I don't see the point.
(As I've already mentioned, I found Peter's use of the word "lie" to
be inappropriate.)
It's a common mistake to assume that "compatible" types are types that
can be assigned back and forth without an explicit cast. (I think
some languages do use the term "compatible" that way.) C's concept of
"compatible types" is much stricter. The main purpose is given in
6.2.7p2:
All declarations that refer to the same object or function shall
have compatible type; otherwise, the behavior is undefined.
And you missed his claim above that
>>>The only compatible type to void * is void *.
A claim that is entirely correct.
Since compatible pointer types are, strictly, defined in terms of
compatibility of the objects they point to, void * is not compatible
with _anything_, not even void *.
Wrong. C99 6.7.5.1p2:
For two pointer types to be compatible, both shall be identically
qualified and both shall be pointers to compatible types.
C90 6.5.4.1 has identical wording.
But, luckily, the standard itself
gives examples of common types of void * and other pointer types,
which common types exist only for compatible types. This should be a
clue that "pointer incompatibility" in the strict sense is not
relevant, and Peter Nilsson is certainly ignorant as well as a troll.
The statement to which Peter was responding was:
There is no pointer type not compatible with it.
*That* statement may not have been relevant to what preceded it, but
that's hardly Peter's fault. Peter's response that "The only
compatible type to void * is void *" was both correct and entirely
relevant to the statement to which he was replying.
So Peter was right, you were wrong, you misrepresented his statement
about the alleged "lie", and yet Peter is the one who is "certainly
ignorant as well as a troll".
Fascinating.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
....
>So Peter was right, you were wrong, you misrepresented his statement
about the alleged "lie", and yet Peter is the one who is "certainly
ignorant as well as a troll".
Fascinating.
Dealing with Marty is always that, and more.
In article <wm***************************@JUPITER.PC-ROSENAU.DE>,
Herbert Rosenau <os****@pc-rosenau.dewrote:
>Casting the result of malloc is an error!
That depends what you mean by "error".
>It will suppress any diagnostic too.
This used to be generally true, but a good compiler can give one
anyway, as gcc does.
>casting is lying to the compiler!
No, in this case it's just being explicit about a conversion that would
be applied anyway.
-- Richard
--
Please remember to mention me / in tapes you leave behind.
Keith Thompson wrote:
pete <pf*****@mindspring.comwrites:
>Richard Heathfield wrote:
>>pete said:
Richard Heathfield wrote:
<snip>
What have I missed?
You missed the part of the thread that had been snipped,
You're right. That's precisely what I missed.
in which
Peter Nilsson wrote:
ptr = (struct some_struct *) malloc(sizeof *ptr);
and Keith Thompson asked:
How is the cast helpful?
and Peter Nilsson replied:
If the pointer types are not compatible,
then a diagnostic is required. [Sound familiar?]
You apparently missed my later followup in which I acknowledged that
he had a reasonable argument in favor of casting the result of malloc.
I don't consider it a convincing argument, but it's a reasonable one.
>>>because Peter Nilsson didn't know what he was talking about.
Um, perhaps so. But might he not have meant that, if ptr is of some
type that is not void * and also is not struct some_struct *, a
diagnostic message would be required, and that he considers this
beneficial? It would be a sort of compile-time assertion that ptr
has type struct some_struct *, yes? I don't say I agree with that by
any means (and in fact I don't think I'm telling you anything new
when I say that I consider the castless version is better style and
more robust), but it seems to me that it needn't necessarily be
ignorance or trolling that led him to that conclusion. It might just
be an alternative point of view, and it seems to me that it's a
defensible one, although I don't happen to agree with it myself.
If ptr is supposed to be (struct some_struct *) and it isn't,
then the problem will show up later in the code when ptr
is being used where a (struct some_struct *) is supposed to be,
and a warning will be generated there.
Catching errors as early as possible is almost always a good thing.
Do you really consider an error caught during compilation
on line 15, to be caught earlier than an error on line 3?
--
pete
Keith Thompson wrote:
Martin Ambuhl <ma*****@earthlink.netwrites:
>Richard Heathfield wrote:
>>Martin Ambuhl said:
Peter Nilsson wrote:
Martin Ambuhl <mamb...@earthlink.netwrote:
>Peter Nilsson wrote:
>><snip>
>malloc returns a void *. There is no pointer type not
>compatible with it. Sound familiar? Get a clue.
It sounds like a lie that's been repeated so often it's
got the status of fact.
>
The only compatible type to void * is void *.
Having proven your ignorance and your trolldom, you may now enter my
killfile.
My curiosity has overcome my reluctance to display my own
ignorance. I have read through the Standard, looking for information
about the compatibility of void * with other types, and I can't find
any. I *did* find the bit about it being okay to convert any object
pointer or incomplete pointer to void * and back without loss of
information - which sure *sounds* like compatibility - but the
Standard does not explicitly state that it *is* compatibility.
What have I missed?
You missed the context, in which Peter Nilsson made the bogus claim
was that casting the return from malloc was a good idea because of a
(completely irrelevant) supposed pointer incompatibility problem.
I didn't find his claim bogus; I found it quite interesting, though I
still don't agree with it. YMMV.
>You missed the line in which Peter Nilsson claimed that anyone who
knew more than he did was lying.
I missed that line as well. He did use the word "lie", but there was
no implication that he was applying it to "anyone who knew more than
he did". I quoted it above; you can see for yourself. I suppose
you're deliberately exaggerating, but I don't see the point.
(As I've already mentioned, I found Peter's use of the word "lie" to
be inappropriate.)
It's a common mistake to assume that "compatible" types are types that
can be assigned back and forth without an explicit cast. (I think
some languages do use the term "compatible" that way.) C's concept of
"compatible types" is much stricter. The main purpose is given in
6.2.7p2:
All declarations that refer to the same object or function shall
have compatible type; otherwise, the behavior is undefined.
>And you missed his claim above that
>>>>The only compatible type to void * is void *.
A claim that is entirely correct.
>Since compatible pointer types are, strictly, defined in terms of
compatibility of the objects they point to, void * is not compatible
with _anything_, not even void *.
Wrong. C99 6.7.5.1p2:
For two pointer types to be compatible, both shall be identically
qualified and both shall be pointers to compatible types.
C90 6.5.4.1 has identical wording.
> But, luckily, the standard itself
gives examples of common types of void * and other pointer types,
which common types exist only for compatible types. This should be a
clue that "pointer incompatibility" in the strict sense is not
relevant, and Peter Nilsson is certainly ignorant as well as a troll.
The statement to which Peter was responding was:
There is no pointer type not compatible with it.
*That* statement may not have been relevant to what preceded it, but
that's hardly Peter's fault. Peter's response that "The only
compatible type to void * is void *" was both correct and entirely
relevant to the statement to which he was replying.
So Peter was right, you were wrong, you misrepresented his statement
about the alleged "lie", and yet Peter is the one who is "certainly
ignorant as well as a troll".
Fascinating.
No.
Peter Nilsson said
"If the pointer types are not compatible,
then a diagnostic is required. [Sound familiar?]"
With the definition of "compatible" that you are now using,
Peter Nilsson's statement is just simply wrong.
--
pete
pete <pf*****@mindspring.comwrites:
Keith Thompson wrote:
>Martin Ambuhl <ma*****@earthlink.netwrites:
[...]
>> But, luckily, the standard itself
gives examples of common types of void * and other pointer types,
which common types exist only for compatible types. This should be a
clue that "pointer incompatibility" in the strict sense is not
relevant, and Peter Nilsson is certainly ignorant as well as a troll.
The statement to which Peter was responding was:
There is no pointer type not compatible with it.
*That* statement may not have been relevant to what preceded it, but
that's hardly Peter's fault. Peter's response that "The only
compatible type to void * is void *" was both correct and entirely
relevant to the statement to which he was replying.
So Peter was right, you were wrong, you misrepresented his statement
about the alleged "lie", and yet Peter is the one who is "certainly
ignorant as well as a troll".
Fascinating.
No.
Peter Nilsson said
"If the pointer types are not compatible,
then a diagnostic is required. [Sound familiar?]"
With the definition of "compatible" that you are now using,
Peter Nilsson's statement is just simply wrong.
The definition of "compatible" that I am now using is the definition
given by the C standard.
Yes, that statement isn't entirely correct, but it's not terribly far
off. The context was:
| Quite so. There is more chance of success with...
|
| ptr = (struct some_struct *) malloc(sizeof *ptr);
| >
| How is the cast helpful?
|
| If the pointer types are not compatible, then a diagnostic
| is required. [Sound familiar?]
The type of the right hand side of the assignment is obviously
``struct some_struct *''. For the assignment to be valid (i.e., not a
constraint violation requiring a diagnostic), either ptr must be of
type void* or the type to which ptr points must be compatible with
``struct some_struct''.
Possibly Peter wasn't 100% clear on the meaning of "compatible types".
(I certainly wasn't until I looked it up for this thread.)
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
pete wrote:
Keith Thompson wrote:
....
>>>>Peter Nilsson wrote:
....
>>>>>The only compatible type to void * is void *.
A claim that is entirely correct.
....
>*That* statement may not have been relevant to what preceded it, but
that's hardly Peter's fault. Peter's response that "The only
compatible type to void * is void *" was both correct and entirely
relevant to the statement to which he was replying.
So Peter was right, you were wrong, you misrepresented his statement
about the alleged "lie", and yet Peter is the one who is "certainly
ignorant as well as a troll".
Fascinating.
No.
Peter Nilsson said
"If the pointer types are not compatible,
then a diagnostic is required. [Sound familiar?]"
With the definition of "compatible" that you are now using,
You make it sound like Keith is inventing this definition; it's the
definition specified by the standard.
Peter Nilsson's statement is just simply wrong.
Yes, that statement was incorrect. His other statement, however, was
correct, and it's the other statement that has been the topic of
discussion for quite a while now.
Richard wrote:
[...] As for the potential for
error from putting the cast in. since the implementation provides the
malloc in 99.9999999999999999999999999999% of instances there really is
not issue since it will be correctly prototyped.
That's an interesting statistic you quote, since it
suggests that you have examined at least 1E30 instances
and found no more than one that was missing a prototype.
Let's see: If you can examine a billion (1E9) C sources
per second, you've been at this for 2600 times the estimated
age of the Universe. I'm astonished at your perseverance --
but not surprised at your, er, "skill" with numbers.
--
Eric Sosman es*****@ieee-dot-org.invalid ja*********@verizon.net wrote:
Martin Ambuhl wrote:
>Richard Heathfield wrote:
>>Martin Ambuhl said:
Peter Nilsson wrote:
....
>>>>The only compatible type to void * is void *.
....
>Since compatible pointer types are, strictly, defined in terms of
compatibility of the objects they point to, void * is not compatible
with _anything_, not even void *.
6.2.7p1 always applies: "Two types have compatible type if their types
are the same."
Is void at type or a non-type?
--
Ian Collins.
Keith Thompson wrote:
pete <pf*****@mindspring.comwrites:
>Keith Thompson wrote:
>>Martin Ambuhl <ma*****@earthlink.netwrites:
[...]
>>> But, luckily, the standard itself
gives examples of common types of void * and other pointer types,
which common types exist only for compatible types. This should be a
clue that "pointer incompatibility" in the strict sense is not
relevant, and Peter Nilsson is certainly ignorant as well as a troll.
The statement to which Peter was responding was:
There is no pointer type not compatible with it.
*That* statement may not have been relevant to what preceded it, but
that's hardly Peter's fault. Peter's response that "The only
compatible type to void * is void *" was both correct and entirely
relevant to the statement to which he was replying.
So Peter was right, you were wrong, you misrepresented his statement
about the alleged "lie", and yet Peter is the one who is "certainly
ignorant as well as a troll".
Fascinating.
No.
Peter Nilsson said
"If the pointer types are not compatible,
then a diagnostic is required. [Sound familiar?]"
With the definition of "compatible" that you are now using,
Peter Nilsson's statement is just simply wrong.
The definition of "compatible" that I am now using is the definition
given by the C standard.
Yes, that statement isn't entirely correct, but it's not terribly far
off. The context was:
| Quite so. There is more chance of success with...
|
| ptr = (struct some_struct *) malloc(sizeof *ptr);
| >
| How is the cast helpful?
|
| If the pointer types are not compatible, then a diagnostic
| is required. [Sound familiar?]
The type of the right hand side of the assignment is obviously
``struct some_struct *''. For the assignment to be valid (i.e., not a
constraint violation requiring a diagnostic), either ptr must be of
type void* or the type to which ptr points must be compatible with
``struct some_struct''.
Possibly Peter wasn't 100% clear on the meaning of "compatible types".
(I certainly wasn't until I looked it up for this thread.)
But "now", he *is* clear.
You can't have both:
"If the pointer types are not compatible,
then a diagnostic is required. [Sound familiar?]"
and
"The only compatible type to void * is void *."
Get what I mean by "now" ?
--
pete
Ian Collins wrote:
ja*********@verizon.net wrote:
>Martin Ambuhl wrote:
>>Richard Heathfield wrote:
Martin Ambuhl said:
Peter Nilsson wrote:
....
>>>>>The only compatible type to void * is void *.
....
>>Since compatible pointer types are, strictly, defined in terms of
compatibility of the objects they point to, void * is not compatible
with _anything_, not even void *.
6.2.7p1 always applies: "Two types have compatible type if their types
are the same."
Is void at type or a non-type?
void is an incomplete type.
There are three major categories of types:
1 object types
2 incomplete types
3 function types
--
pete
James Kuyper wrote:
pete wrote:
>Keith Thompson wrote:
...
>>>>>Peter Nilsson wrote:
...
>>>>>>The only compatible type to void * is void *.
A claim that is entirely correct.
...
>>*That* statement may not have been relevant to what preceded it, but
that's hardly Peter's fault. Peter's response that "The only
compatible type to void * is void *" was both correct and entirely
relevant to the statement to which he was replying.
So Peter was right, you were wrong, you misrepresented his statement
about the alleged "lie", and yet Peter is the one who is "certainly
ignorant as well as a troll".
Fascinating.
No.
Peter Nilsson said
"If the pointer types are not compatible,
then a diagnostic is required. [Sound familiar?]"
With the definition of "compatible" that you are now using,
You make it sound like Keith is inventing this definition; it's the
definition specified by the standard.
>Peter Nilsson's statement is just simply wrong.
Yes, that statement was incorrect. His other statement, however, was
correct, and it's the other statement that has been the topic of
discussion for quite a while now.
No.
It was Martin Ambuhl's dispute with what Peter Nilsson wrote
that has been the subject of discussion.
Both Richard Heathfield and Keith Thompson have suggested that
Peter Nilsson may have used the word "compatible"
to mean something else.
After Peter Nilsson wrote
"The only compatible type to void * is void *."
nobody disputed that statement.
--
pete
pete wrote:
Ian Collins wrote:
>ja*********@verizon.net wrote:
>>Martin Ambuhl wrote:
Richard Heathfield wrote:
Martin Ambuhl said:
>
>Peter Nilsson wrote:
....
>>The only compatible type to void * is void *.
....
Since compatible pointer types are, strictly, defined in terms of
compatibility of the objects they point to, void * is not compatible
with _anything_, not even void *.
6.2.7p1 always applies: "Two types have compatible type if their types
are the same."
Is void at type or a non-type?
void is an incomplete type.
There are three major categories of types:
1 object types
2 incomplete types
3 function types
So can incomplete types be the same?
--
Ian Collins.
Eric Sosman wrote:
Richard wrote:
>[...] As for the potential for
error from putting the cast in. since the implementation provides the
malloc in 99.9999999999999999999999999999% of instances there really is
not issue since it will be correctly prototyped.
That's an interesting statistic you quote, since it
suggests that you have examined at least 1E30 instances
and found no more than one that was missing a prototype.
Let's see: If you can examine a billion (1E9) C sources
per second, you've been at this for 2600 times the estimated
age of the Universe. I'm astonished at your perseverance --
but not surprised at your, er, "skill" with numbers.
It's actually 100%, for hosted implementations.
If you don't have malloc,
then you don't have a hosted C implementation.
--
pete
Ian Collins wrote:
pete wrote:
>>
There are three major categories of types:
1 object types
2 incomplete types
3 function types
So can incomplete types be the same?
Yes. A void is a void is a void. Also, an int[] (as
in `extern int array[];') is an int[] is an int[]. And a
struct foo is a struct foo is a struct foo, and a union bar
is a union bar is a union bar.
However, a void is not an int[] is not a struct foo
is not a union bar.
--
Eric Sosman es*****@ieee-dot-org.invalid
Ian Collins wrote:
pete wrote:
>Ian Collins wrote:
>>ja*********@verizon.net wrote:
Martin Ambuhl wrote:
Richard Heathfield wrote:
>Martin Ambuhl said:
>>
>>Peter Nilsson wrote:
....
>>>The only compatible type to void * is void *.
....
Since compatible pointer types are, strictly, defined in terms of
compatibility of the objects they point to, void * is not compatible
with _anything_, not even void *.
6.2.7p1 always applies: "Two types have compatible type if their types
are the same."
Is void at type or a non-type?
void is an incomplete type.
There are three major categories of types:
1 object types
2 incomplete types
3 function types
So can incomplete types be the same?
I don't understand.
Now that you know that void is a type,
are you asking if void can be the same as void?
--
pete
Ian Collins wrote:
pete wrote:
>Ian Collins wrote:
>>ja*********@verizon.net wrote:
Martin Ambuhl wrote:
Richard Heathfield wrote:
>Martin Ambuhl said:
>>
>>Peter Nilsson wrote:
....
>>>The only compatible type to void * is void *.
....
Since compatible pointer types are, strictly, defined in terms of
compatibility of the objects they point to, void * is not compatible
with _anything_, not even void *.
6.2.7p1 always applies: "Two types have compatible type if their types
are the same."
Is void at type or a non-type?
void is an incomplete type.
There are three major categories of types:
1 object types
2 incomplete types
3 function types
So can incomplete types be the same?
They are certainly be the same as themselves.
Of course, while void in an incomplete type, "void*" is a complete type,
so the issue doesn't come up in this context
pete wrote:
James Kuyper wrote:
>pete wrote:
....
>>Peter Nilsson said
"If the pointer types are not compatible,
then a diagnostic is required. [Sound familiar?]"
With the definition of "compatible" that you are now using,
You make it sound like Keith is inventing this definition; it's the
definition specified by the standard.
>>Peter Nilsson's statement is just simply wrong.
Yes, that statement was incorrect. His other statement, however, was
correct, and it's the other statement that has been the topic of
discussion for quite a while now.
No.
It was Martin Ambuhl's dispute with what Peter Nilsson wrote
that has been the subject of discussion.
Both Richard Heathfield and Keith Thompson have suggested that
Peter Nilsson may have used the word "compatible"
to mean something else.
I also believe that this is probably the explanation for Peter's
incorrect statement. Whether or not he had the same incorrect concept of
"compatible" in mind when he wrote the other statement isn't clear. If
so, then what he understood by that statement would have been incorrect.
However, as actually written, that statement is correct.
After Peter Nilsson wrote
"The only compatible type to void * is void *."
nobody disputed that statement.
Martin Ambuhl's immediate response to Peter's message containing those
words was "Having proven your ignorance ...". That sounds to me like an
implicit rejection of the validity of that statement. However, it could
plausibly be a reference to some other ignorance Martin perceived for
the first time in that message.
Martin later clarified the fact that he was indeed disputing precisely
that statement, and made his own incorrect understanding of the issue
very clear, by saying:
Since compatible pointer types are, strictly, defined in terms of
compatibility of the objects they point to, void * is not compatible
with _anything_, not even void *.
pete wrote:
Ian Collins wrote:
>pete wrote:
>>Ian Collins wrote:
ja*********@verizon.net wrote:
Martin Ambuhl wrote:
>Richard Heathfield wrote:
>>Martin Ambuhl said:
>>>
>>>Peter Nilsson wrote:
....
>>>>The only compatible type to void * is void *.
....
>Since compatible pointer types are, strictly, defined in terms of
>compatibility of the objects they point to, void * is not compatible
>with _anything_, not even void *.
6.2.7p1 always applies: "Two types have compatible type if their types
are the same."
>
Is void at type or a non-type?
void is an incomplete type.
There are three major categories of types:
1 object types
2 incomplete types
3 function types
So can incomplete types be the same?
I don't understand.
Now that you know that void is a type,
are you asking if void can be the same as void?
Oh I knew all along, I was just getting the thread back to basics.
A little Friday afternoon pre-pub fun.
--
Ian Collins.
James Kuyper wrote:
pete wrote:
>After Peter Nilsson wrote
"The only compatible type to void * is void *."
nobody disputed that statement.
Martin later clarified the fact that he was indeed disputing precisely
that statement, and made his own incorrect understanding of the issue
very clear, by saying:
Since compatible pointer types are, strictly, defined in terms of
compatibility of the objects they point to, void * is not compatible
with _anything_, not even void *.
I missed that.
You're right; I'm wrong.
--
pete
pete wrote:
After Peter Nilsson wrote
"The only compatible type to void * is void *."
nobody disputed that statement.
No, I incorrectly disputed that statement. It was a residual response
to his claims about "pointer compatibility" somehow being the
justification for casting the return to void. His subsequent labeling
of anyone who disagreed or might be in error as liars didn't help. Most
of this thread is due to my incorrect, erroneous response to the above.
But Perer, of course, claims not that I was wrong but that I am a
liar. I should apologize to the newgroup for launching a never-ending
to-and-fro derived from my error. I will, of course, never apologize to
the brutish Peter Nilsson, who instead owes an apology to everyone else.
Martin Ambuhl wrote:
pete wrote:
>After Peter Nilsson wrote
"The only compatible type to void * is void *."
nobody disputed that statement.
No, I incorrectly disputed that statement.
I blew it that time.
--
pete
Martin Ambuhl <ma*****@earthlink.netwrites:
pete wrote:
>After Peter Nilsson wrote
"The only compatible type to void * is void *."
nobody disputed that statement.
No, I incorrectly disputed that statement. It was a residual response
to his claims about "pointer compatibility" somehow being the
justification for casting the return to void. His subsequent labeling
of anyone who disagreed or might be in error as liars didn't help.
Most of this thread is due to my incorrect, erroneous response to the
above. But Perer, of course, claims not that I was wrong but that I am
a liar. I should apologize to the newgroup for launching a
never-ending to-and-fro derived from my error. I will, of course,
never apologize to the brutish Peter Nilsson, who instead owes an
apology to everyone else.
Grow up. Demanding apologies is so Heathfield'esque and, frankly, rather
pathetic. It is the ONLY newsgroup I have seen it in. To acknowledge an
error however will ensure you go to Heaven. As for "Brutish Peter
Nilsson", diddums - if you want to play with the big boys then take it
like a man. Lets face it, you're not averse to insulting people (as you
just did) yourself.
In article <g9**********@registered.motzarella.org>,
Richard <rg****@gmail.comwrote:
....
>Grow up. Demanding apologies is so Heathfield'esque and, frankly, rather
pathetic. It is the ONLY newsgroup I have seen it in. To acknowledge an
error however will ensure you go to Heaven. As for "Brutish Peter
Nilsson", diddums - if you want to play with the big boys then take it
like a man. Lets face it, you're not averse to insulting people (as you
just did) yourself.
Note that Marty is nuts even by the standards of this NG. CBF is like
nothing compared to him. Marty is the same way over on rec.games.bridge
(and probably others - but these are the only 2 NGs of which I am aware
that he posts).
But, yeah, I love the idea of somebody keeping a database (which, one
would hope, would be accessible online) of apologies owed and apologies
made - for the CLC newsgroup.
pete <pf*****@mindspring.comwrites:
Keith Thompson wrote:
[...]
>Possibly Peter wasn't 100% clear on the meaning of "compatible
types".
(I certainly wasn't until I looked it up for this thread.)
But "now", he *is* clear.
Presumably.
You can't have both:
"If the pointer types are not compatible,
then a diagnostic is required. [Sound familiar?]"
and
"The only compatible type to void * is void *."
Get what I mean by "now" ?
The first statement was incorrect (though, as I explained, not
horribly incorrect). It was an error that I didn't catch at the time.
The second statement is correct; void* is the only type that's
compatible with void*.
Yes, I know what "now" means; why do you ask?
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Martin Ambuhl <ma*****@earthlink.netwrites:
pete wrote:
>After Peter Nilsson wrote
"The only compatible type to void * is void *."
nobody disputed that statement.
No, I incorrectly disputed that statement. It was a residual response
to his claims about "pointer compatibility" somehow being the
justification for casting the return to void.
Fair enough.
His subsequent labeling
of anyone who disagreed or might be in error as liars didn't help.
Most of this thread is due to my incorrect, erroneous response to the
above. But Perer, of course, claims not that I was wrong but that I am
a liar.
No, he did not.
One more time, here's the actual quotation:
| Peter Nilsson wrote:
| Martin Ambuhl <mamb...@earthlink.netwrote:
| >Peter Nilsson wrote:
| >><snip>
| >malloc returns a void *. There is no pointer type not
| >compatible with it. Sound familiar? Get a clue.
| It sounds like a lie that's been repeated so often it's
| got the status of fact.
| The only compatible type to void * is void *.
I object to Peter's use of the word "lie" to refer to an honest
misunderstanding, but he did not call you or anyone else a liar.
There are numerous examples of false statements that started out as
deliberate lies, but have since been passed on and repeated by other
people who honestly believe them to be true. Furthermore, he said it
*sounds* like a lie, not that it is one. I suggest that you're being
overly sensitive. In my opinion, Peter chose his words poorly, but I
don't believe he intended to accuse you of being a liar.
I should apologize to the newgroup for launching a
never-ending to-and-fro derived from my error. I will, of course,
never apologize to the brutish Peter Nilsson, who instead owes an
apology to everyone else.
"That trick never works." -- Rocket J. Squirrel
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
pete <pf*****@mindspring.comwrites:
Eric Sosman wrote:
>Richard wrote:
>>[...] As for the potential for
error from putting the cast in. since the implementation provides the
malloc in 99.9999999999999999999999999999% of instances there really is
not issue since it will be correctly prototyped.
That's an interesting statistic you quote, since it
suggests that you have examined at least 1E30 instances
and found no more than one that was missing a prototype.
Let's see: If you can examine a billion (1E9) C sources
per second, you've been at this for 2600 times the estimated
age of the Universe. I'm astonished at your perseverance --
but not surprised at your, er, "skill" with numbers.
It's actually 100%, for hosted implementations.
If you don't have malloc,
then you don't have a hosted C implementation.
It's true that any conforming hosted C implementation provides malloc.
It does not follow from this that it will be correctly prototyped. In
particular, if you forget the "#include <stdlib.h>", then it will
*not* be correctly prototyped (unless you manually prototype it
yourself). It's true that many C90 compilers, and all conforming C99
compilers, will issue a diagnostic for a call to malloc with no
visible declaration, but cases of *both* using a compiler that doesn't
warn about a call to an undeclared function *and* casting the result
of malloc are far more common than one case in 1E30.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson wrote:
pete <pf*****@mindspring.comwrites:
>Keith Thompson wrote:
[...]
>>Possibly Peter wasn't 100% clear on the meaning of "compatible
types".
(I certainly wasn't until I looked it up for this thread.)
But "now", he *is* clear.
Presumably.
>You can't have both:
"If the pointer types are not compatible,
then a diagnostic is required. [Sound familiar?]"
and
"The only compatible type to void * is void *."
Get what I mean by "now" ?
The first statement was incorrect (though, as I explained, not
horribly incorrect). It was an error that I didn't catch at the time.
The second statement is correct; void* is the only type that's
compatible with void*.
Yes, I know what "now" means; why do you ask?
Because the meaning that you're using now
is different from the meaning that was possibly meant
when you said that he possibly wasn't 100% clear on the meaning,
when you weren't either.
--
pete
pete <pf*****@mindspring.comwrites:
Keith Thompson wrote:
>pete <pf*****@mindspring.comwrites:
>>Keith Thompson wrote:
[...]
>>>Possibly Peter wasn't 100% clear on the meaning of "compatible
types".
(I certainly wasn't until I looked it up for this thread.)
But "now", he *is* clear.
Presumably.
>>You can't have both:
"If the pointer types are not compatible,
then a diagnostic is required. [Sound familiar?]"
and
"The only compatible type to void * is void *."
Get what I mean by "now" ?
The first statement was incorrect (though, as I explained, not
horribly incorrect). It was an error that I didn't catch at the time.
The second statement is correct; void* is the only type that's
compatible with void*.
Yes, I know what "now" means; why do you ask?
Because the meaning that you're using now
is different from the meaning that was possibly meant
when you said that he possibly wasn't 100% clear on the meaning,
when you weren't either.
Yes, that's true.
It seems to me that I made a fairly obvious point, and you posted to
say that you agree with that point, but with a rather odd emphasis on
the word "now" and a tone that suggested some disagreement.
I'm perfectly willing to drop this and live with the confusion.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson wrote:
No, he did not.
One more time, here's the actual quotation:
| Peter Nilsson wrote:
| Martin Ambuhl <mamb...@earthlink.netwrote:
| >Peter Nilsson wrote:
| >><snip>
| >malloc returns a void *. There is no pointer type not
| >compatible with it. Sound familiar? Get a clue.
| It sounds like a lie that's been repeated so often it's
| got the status of fact.
| The only compatible type to void * is void *.
I object to Peter's use of the word "lie" to refer to an honest
misunderstanding, but he did not call you or anyone else a liar.
This is sophistry: a lie is a statement. It is made by someone. There
is no lie without a liar.
Martin Ambuhl wrote:
Keith Thompson wrote:
No, he did not.
One more time, here's the actual quotation:
| Peter Nilsson wrote:
| Martin Ambuhl <mamb...@earthlink.netwrote:
| >Peter Nilsson wrote:
| >><snip>
| >malloc returns a void *. There is no pointer type not
| >compatible with it. Sound familiar? Get a clue.
| It sounds like a lie that's been repeated so often it's
| got the status of fact.
| The only compatible type to void * is void *.
I object to Peter's use of the word "lie" to refer to an honest
misunderstanding, but he did not call you or anyone else a liar.
This is sophistry: a lie is a statement. It is made by someone. There
is no lie without a liar.
A liar can make a statement, yet have it repeated by other people who
think it is true. The fact that they said something which is a lie
does not make them liars, it just means that they are mistaken.
Peter's wording avoids attributing the lie to you; he left open the
possibility that you were were not aware of the fact that your
statement was incorrect.
Personally, I don't think that even the originator of this statement
was necessarily lying; he might have thought he was telling the truth.
As Hanlon's Razor says, "Never attribute to malice that which can be
adequately explained by stupidity."
Martin Ambuhl <ma*****@earthlink.netwrites:
Keith Thompson wrote:
>No, he did not.
One more time, here's the actual quotation:
| Peter Nilsson wrote:
| Martin Ambuhl <mamb...@earthlink.netwrote:
| >Peter Nilsson wrote:
| >><snip>
| >malloc returns a void *. There is no pointer type not
| >compatible with it. Sound familiar? Get a clue.
| It sounds like a lie that's been repeated so often it's
| got the status of fact.
| The only compatible type to void * is void *.
I object to Peter's use of the word "lie" to refer to an honest
misunderstanding, but he did not call you or anyone else a liar.
This is sophistry: a lie is a statement. It is made by someone.
There is no lie without a liar.
Nobody said *you* were the liar. You snipped the part where I
explained this, and where I pointed that he merely said it *sounds*
like a lie.
I suggest dropping this until and unless Peter explains what he meant
(though I wouldn't blame him for staying away from this thread).
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Martin Ambuhl said:
Keith Thompson wrote:
>No, he did not.
One more time, here's the actual quotation:
| Peter Nilsson wrote:
| Martin Ambuhl <mamb...@earthlink.netwrote:
| >Peter Nilsson wrote:
| >><snip>
| >malloc returns a void *. There is no pointer type not
| >compatible with it. Sound familiar? Get a clue.
| It sounds like a lie that's been repeated so often it's
| got the status of fact.
| The only compatible type to void * is void *.
I object to Peter's use of the word "lie" to refer to an honest
misunderstanding, but he did not call you or anyone else a liar.
This is sophistry: a lie is a statement. It is made by someone. There
is no lie without a liar.
It's not sophistry. I can now see why you interpreted the statement as you
did, but it took me a few tries. There /is/ another way to read it, one
that is not even remotely offensive. In the absence of any evidence to the
contrary, I would suggest that you take the charitable route of assuming
that Peter N simply chose his words badly.
And even if he meant to call you a liar (which I really, really doubt): I
seem to recall that, a decade or so ago, your sig block ran something like
"if you're going to post to Usenet, you should cultivate a thick skin".
Excellent advice.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Richard Bos <rl*@hoekstra-uitgeverij.nlwrote in message
news:48****************@news.xs4all.nl...
Nick Keighley <ni******************@hotmail.comwrote:
On 26 Aug, 01:48, "Bill Reid" <hormelf...@happyhealthy.netwrote:
At the risk of repeating myself, I'm going to repeat myself:
>
"It's completely friggin' impossible to learn all the bass-ackwards
and semi-sideways inconsistent methods of declaring and
dereferencing pointers in "C". =A0NO non-lunatic has ever been able
to grasp the total non-logic of the topic
so what is a simple, easy to learn, well defined language.
What would *you* recommend?
For Bill? Logo. _With_ turtle.
Close! JavaScript!!!
---
William Ernest Reid
In article <g9**********@registered.motzarella.org>,
Martin Ambuhl <ma*****@earthlink.netwrote:
....
>This is sophistry: a lie is a statement. It is made by someone. There
is no lie without a liar.
Let's not quit our day job, and try to get into something more
lucrative, like international diplomacy, OK then?
On Thu, 28 Aug 2008 20:44:07 UTC, Harald van Dk <tr*****@gmail.com>
wrote:
On Thu, 28 Aug 2008 19:57:44 +0000, Herbert Rosenau wrote:
Casting the result of malloc is an error!
No, it isn't. Relying on an implicit function declaration of malloc is an
error. Casting its result may hide that error, but that doesn't make the
cast the problem.
It will suppress any
diagnostic too.
Leeav off any casting will giv you a diagnostic when you have failed to
#include <stdlib.has you should to get the correct prototype of malloc
in sight.
C99 requires a diagnostic when an undeclared function is called,
and a caast will suppress the diagnostic and let you convert the wrong
value to a pointer. Not
and C90
implementations commonly at least have an option to warn for this as well.
but will suppress the diagnostic too because you are lying to it.
Leaving off the cast will not necessarily give you any more diagnostics
than including it.
Casting will hide any diagnostic.
In C90 and newer yoll get a diagnostict when vou've forgotten to
#include <stdlib.h>. It doesn't matter what the diagnostic says. The
meaning is always: you've forgotten the #include. The speaking says
only something about the stage the compiler fails because the retutn
type seen on lefthand side is incoumpatible to the type on right hand
side of the operator.
The fine on C99 is that void* is always compatible to <type>*. So
casting is supoerflous in any case since K&R 1.
However casting is superflous in nearly all cases it sseems so. So it
is always a good idea to avoid it una use it only when you exactly
knows why you must cast. Suppressing a diagnostic only to suppress it
is not a solution but an error.
Once again: C++ is NOT C. When you really, really have to write C in
C++ you knows how ro say to the C++compiler that you are writing C now
and when that ends and your C++ compiler will follow you.
There is no guarantee that any result will be stored into exactly the
same place and will have the same bit wide. Casing something to a
pointer type resulsts in hitting a value NOT returned by the function.
Converting that to the destination pointer is playing russian roulett.
--
Tschau/Bye
Herbert
Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!
Herbert Rosenau wrote, On 22/09/08 22:04:
On Thu, 28 Aug 2008 20:44:07 UTC, Harald van D�k <tr*****@gmail.com>
wrote:
>On Thu, 28 Aug 2008 19:57:44 +0000, Herbert Rosenau wrote:
>>Casting the result of malloc is an error!
No, it isn't. Relying on an implicit function declaration of malloc is an
error. Casting its result may hide that error, but that doesn't make the
cast the problem.
>>It will suppress any
diagnostic too.
Leeav off any casting will giv you a diagnostic when you have failed to
#include <stdlib.has you should to get the correct prototype of malloc
in sight.
C99 requires a diagnostic when an undeclared function is called,
and a caast will suppress the diagnostic and let you convert the wrong
value to a pointer. Not
In C99 the diagnostic is still required in the presence of a cast. The
diagnostic is required due to the lack of a declaration for malloc and
has absolutely nothing to do with pointers and integers being incompatible.
and C90
>implementations commonly at least have an option to warn for this as well.
but will suppress the diagnostic too because you are lying to it.
Depends. If the option is to warn about use of unprototyped (or
undeclared) functions it won't suppress it since malloc still has no
prototype or declaration in scope.
>Leaving off the cast will not necessarily give you any more diagnostics
than including it.
Casting will hide any diagnostic.
<snip>
No, it will hide some diagnostics. It will not hide the diagnostic C99
would still require not the optional diagnostics that at least some
compilers have.
I agree that casting the result of malloc is pointless and in general
bad practice, just not with the specific points above.
--
Flash Gordon
If spamming me sent it to sm**@spam.causeway.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/
Herbert Rosenau wrote:
On Thu, 28 Aug 2008 20:44:07 UTC, Harald van Dk <tr*****@gmail.com>
wrote:
On Thu, 28 Aug 2008 19:57:44 +0000, Herbert Rosenau wrote:
Casting the result of malloc is an error!
....
C99 requires a diagnostic when an undeclared function is called,
and a caast will suppress the diagnostic and let you convert the wrong
value to a pointer. Not
and C90
I think you're mixed up. Casts can change the type of an expression,
and as a result they can suppress diagnostics that are related to type
mis-matches. However, a cast cannot be used to change the name of a
function, and if that name does not match any declared identifier
currently in scope, no cast will turn off the diagnostic that comes
from using it.
However, if you think otherwise, could you give us an example of how
this could be done? I strongly recommend attempting to compile your
example before posting it, to verify that the diagnostic is indeed
suppressed.
Leaving off the cast will not necessarily give you any more diagnostics
than including it.
Casting will hide any diagnostic.
Please show us how a cast can be used to remove the diagnostic that is
mandatory when I write code containing the line:
#include "file_which_does_not.exist_on_my_system"
(assume that the file name given correctly describes the situation).
However casting is superflous in nearly all cases it sseems so. So it
double d;
void *p = &d;
*(double*)p = 3.0;
Assume that the cast occurs in a different translation unit than the
one where 'd' is declared with block scope; they communicate via p,
and the cast occurs at a point where it is known that p points at a
double.. Show me exactly how the cast is superfluous.
On a system where (void*) and &d have different and incompatible
representations, explain exactly how the following cast is
superfluous:
printf("%p\n", (void*)&d);
Explain how either of the casts in the following function are
superfluous:
void call_func( (void(*func)(), enum functype type, void* argument)
{
switch(type)
{
case VOIDFUNCINT: (void(*)(int))func) (*(int*)argument);
...
} ja*********@verizon.net writes:
Herbert Rosenau wrote:
[...]
>However casting is superflous in nearly all cases it sseems so. So it
double d;
void *p = &d;
*(double*)p = 3.0;
Assume that the cast occurs in a different translation unit than the
one where 'd' is declared with block scope; they communicate via p,
and the cast occurs at a point where it is known that p points at a
double.. Show me exactly how the cast is superfluous.
It's not *directly* superfluous, but it can be eliminated easily
enough:
double d;
void *p = &d;
double *tmp = p;
*tmp = 3.0;
On a system where (void*) and &d have different and incompatible
representations, explain exactly how the following cast is
superfluous:
printf("%p\n", (void*)&d);
As above, you *could* avoid the cast by assigning &d to a temporary.
Personally, I find the cast clearer.
Explain how either of the casts in the following function are
superfluous:
void call_func( (void(*func)(), enum functype type, void* argument)
{
switch(type)
{
case VOIDFUNCINT: (void(*)(int))func) (*(int*)argument);
...
}
Aside from the mismatched parentheses, you can do this with a
temporary as well -- and the cast on func really is superfluous.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister" This thread has been closed and replies have been disabled. Please start a new discussion. |
