473,397 Members | 2,099 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,397 software developers and data experts.

malloc() and implicit cast

I have checked the FAQ: http://c-faq.com/malloc/mallocnocast.html
FAQ discusses a special case when programmer has forgotten to do
#include <stdlib.h>. I am including this header and I am not doing any
explicit cast:

#include <stdlib.h>
enum ARRSIZE { MAXSIZE = 100 };
struct dummy
{
int i;
};
int main( void )
{

char *pc;
struct dummy *ptrDummy;

pc = malloc( MAXSIZE );
ptrDummy=malloc(sizeof(struct dummy));

return 0;
}

============ OUTPUT ============
/home/arnuld/programs/C $ gcc -ansi -pedantic -Wall -Wextra test.c
/home/arnuld/programs/C $ ./a.out
/home/arnuld/programs/C $

malloc(size_t n) returns a void pointer and here in my program, I am
assigning malloc returned pointers to 2 different types and I am not
getting any warnings about <implicit cast>.
It has something to do with C90 ?


--
http://lispmachine.wordpress.com/
Jun 27 '08 #1
17 2478
arnuld wrote:

I don't understand. Do you think there /should/ be a problem?

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto/
Jun 27 '08 #2
"arnuld" <ul**@kullu.comwrote in message
news:pa****************************@kullu.com...
>I have checked the FAQ: http://c-faq.com/malloc/mallocnocast.html

FAQ discusses a special case when programmer has forgotten to do
#include <stdlib.h>. I am including this header and I am not doing any
explicit cast:
There is no such thing as an "explicit cast". There are implicit and
explicit conversions; the latter uses a cast, and the former does not.
#include <stdlib.h>
....
char *pc;
struct dummy *ptrDummy;

pc = malloc( MAXSIZE );
ptrDummy=malloc(sizeof(struct dummy));
....
malloc(size_t n) returns a void pointer and here in my program, I am
assigning malloc returned pointers to 2 different types and I am not
getting any warnings about <implicit cast>.
There is no such thing as an "implicit cast". There are implicit and
explicit conversions; the latter uses a cast, and the former does not.

Second, a warning is only expected when you _don't_ include the proper
header and you _don't_ use a cast. Since you're including the proper
header, there is no reason for a warning.

What's the problem?

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

Jun 27 '08 #3
arnuld wrote:
I have checked the FAQ: http://c-faq.com/malloc/mallocnocast.html
OK.
FAQ discusses a special case when programmer has forgotten to do
#include <stdlib.h>. I am including this header and I am not doing any
explicit cast:
Yes, that how it should be, if you really read the FAQ: include the header,
don't use the cast.
malloc(size_t n) returns a void pointer and here in my program, I am
assigning malloc returned pointers to 2 different types and I am not
getting any warnings about <implicit cast>.
Of course, you don't. In C language 'void*' pointers are implicitly convertible
to and from other pointer types. What warnings did you expect and why?

--
Best regards,
Andrey Tarasevich
Jun 27 '08 #4
On Tue, 15 Apr 2008 08:13:43 -0700, Andrey Tarasevich
<an**************@hotmail.comwrote in comp.lang.c:
arnuld wrote:
I have checked the FAQ: http://c-faq.com/malloc/mallocnocast.html

OK.
FAQ discusses a special case when programmer has forgotten to do
#include <stdlib.h>. I am including this header and I am not doing any
explicit cast:

Yes, that how it should be, if you really read the FAQ: include the header,
don't use the cast.
malloc(size_t n) returns a void pointer and here in my program, I am
assigning malloc returned pointers to 2 different types and I am not
getting any warnings about <implicit cast>.

Of course, you don't. In C language 'void*' pointers are implicitly convertible
to and from other pointer types. What warnings did you expect and why?
To and from other object pointer type. There is no defined conversion
between pointers to functions and pointers to object types, even
incomplete object types like void.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
Jun 27 '08 #5
Jack Klein wrote:
Andrey Tarasevich <an**************@hotmail.comwrote:
arnuld wrote:
I have checked the FAQ:
http://c-faq.com/malloc/mallocnocast.html
FAQ discusses a special case when programmer has
forgotten to do #include <stdlib.h>. I am including
this header and I am not doing any explicit cast:
Yes, that how it should be, if you really read the
FAQ: include the header, don't use the cast.
I _really_ read the FAQ and took notice of the parenthetical
comment at the end. It highlights that the real issue lies
with using unprototyped functions. Sensible programmers
will use compilers that advise of such things. [Of course,
conforming C90 compilers are not required to issue
diagnostics, but nevertheless the issue has been around
long enough that you'll be hard pressed to find any
conforming compiler that isn't capable of alerting you
to the use of an unprototyped function. Personally, I
think a C programmer be insane not to use that feature
if it was available.]
malloc(size_t n) returns a void pointer and here
in my program, I am assigning malloc returned
pointers to 2 different types and I am not
getting any warnings about <implicit cast>.
Of course, you don't. In C language 'void*' pointers
are implicitly convertible to and from other pointer
types. What warnings did you expect and why?

To and from other object pointer type. There is no
defined conversion between pointers to functions and
pointers to object types, even incomplete object types
like void.
Except for the case of null pointer constants.

--
Peter
Jun 27 '08 #6
On Tue, 15 Apr 2008 21:00:17 -0500, Jack Klein wrote:
>On Tue, 15 Apr 2008 08:13:43 -0700, Andrey Tarasevich
Of course, you don't. In C language 'void*' pointers are implicitly
convertible to and from other pointer types. What warnings did you
expect and why?
To and from other object pointer type. There is no defined conversion
between pointers to functions and pointers to object types, even
incomplete object types like void.
so an int* is implicitly converted to a void* which then can be
implicitly converted to char* without any warning at all.

--
http://lispmachine.wordpress.com/

find my email ID at the above address.
Jun 27 '08 #7
On Tue, 15 Apr 2008 21:00:17 -0500, Jack Klein wrote:
To and from other object pointer type. There is no defined conversion
between pointers to functions and pointers to object types, even
incomplete object types like void.
so I conlcude:

1.) Function Pointers: pointer to function returning an int can be
implicitly converted into char* without any any warning message.

2.) Pointers to object types: compiler can implicitly convert and int*
into char* without any warning message to the programmer. C doe snot
require any warning in this case

Is that what you mean ?


--
http://lispmachine.wordpress.com/
Jun 27 '08 #8
arnuld wrote:
Jack Klein wrote:
Andrey Tarasevich:
Of course, you don't. In C language 'void*' pointers are implicitly
convertible to and from other pointer types. What warnings did you
expect and why?
To and from other object pointer type. There is no defined conversion
between pointers to functions and pointers to object types, even
incomplete object types like void.

so an int* is implicitly converted to a void*
What int*?
which then can be implicitly converted to char* without any
warning at all.
Consider...

int *ip = malloc(N * sizeof *ip);

The malloc function knows nothing about the type being allocated.
It returns a void * to a region suitably aligned for any object.

There is an implicit conversion from void * to int * in the assignment
of the void * to ip, but as you say there is (generally) no warning.
Nor should you expect there to be one. The implicit conversion of
void * to and from other object or incomplete types is a language
_feature_. [Not necessarily a good one, but a deliberate feature
nonetheless.]

--
Peter
Jun 27 '08 #9
arnuld said:
>On Tue, 15 Apr 2008 21:00:17 -0500, Jack Klein wrote:
>To and from other object pointer type. There is no defined conversion
between pointers to functions and pointers to object types, even
incomplete object types like void.

so I conlcude:

1.) Function Pointers: pointer to function returning an int can be
implicitly converted into char* without any any warning message.
I don't see why you conclude this from what Jack said, because it simply
isn't true. A pointer to function, of no matter what return type, cannot
be implicitly converted into *any* other type, let alone a char *.
2.) Pointers to object types: compiler can implicitly convert and int*
into char* without any warning message to the programmer.
No, there is no implicit conversion between int * and char *.
C [does not] require any warning in this case
Implementations are required to diagnose an attempt to assign int * to char
* and vice versa.
Is that what you mean ?
I doubt it, because it's completely wrong.

--
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
Jun 27 '08 #10
Richard Heathfield wrote:
...A pointer to function, of no matter what return type, cannot
be implicitly converted into *any* other type, let alone a char *.
Actually, they can be implicitily converted in limited cases...

int main(int argc, char **argv)
{
int (*fp)() = main; /* okay */
return 0;
}

--
Peter
Jun 27 '08 #11
Peter Nilsson said:
Richard Heathfield wrote:
>...A pointer to function, of no matter what return type, cannot
be implicitly converted into *any* other type, let alone a char *.

Actually, they can be implicitily converted in limited cases...

int main(int argc, char **argv)
{
int (*fp)() = main; /* okay */
return 0;
}
ANY dogmatic assertion, no matter how obviously correct, has a
counter-example that disproves it. :-)

In this case, you're dodging round the type system by missing out the
parameter list from fp's type - and yes, that is a valid demonstration
that the type system for function pointers isn't quite as bullet-proof as
I'd suggested. (That doesn't mean that it's a good idea, of course, to do
such dodgery - but it can be a very present help in time of trouble).

--
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
Jun 27 '08 #12
arnuld wrote:
>Jack Klein wrote:
.... snip ...
>>
To and from other object pointer type. There is no defined
conversion between pointers to functions and pointers to object
types, even incomplete object types like void.

so an int* is implicitly converted to a void* which then can be
implicitly converted to char* without any warning at all.
No, that is a programming error. That particular void* can be
converted back into an int* without loss, but other conversions
(implicit or not) are NOT guaranteed.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

** Posted from http://www.teranews.com **
Jun 27 '08 #13
CBFalconer wrote:
arnuld wrote:
>>Jack Klein wrote:
... snip ...
>>To and from other object pointer type. There is no defined
conversion between pointers to functions and pointers to object
types, even incomplete object types like void.
so an int* is implicitly converted to a void* which then can be
implicitly converted to char* without any warning at all.

No, that is a programming error. That particular void* can be
converted back into an int* without loss, but other conversions
(implicit or not) are NOT guaranteed.
In the particular case of thing* to or from char* it's
not ipso facto an error: C specifically permits accessing
an object's representation as an array of char.

A better example might be double* to void* to int*,
which is either an error or at best a dubious practice.

--
Er*********@sun.com
Jun 27 '08 #14
arnuld wrote:
>
>To and from other object pointer type. There is no defined conversion
between pointers to functions and pointers to object types, even
incomplete object types like void.

so I conlcude:

1.) Function Pointers: pointer to function returning an int can be
implicitly converted into char* without any any warning message.
??? I don't know where you draw that "conclusion" from. Function pointers
_cannot_ be implicitly converted to object pointers. That's what has been said
so far. How you ended up concluding the opposite is beyond me.
2.) Pointers to object types: compiler can implicitly convert and int*
into char* without any warning message to the programmer. C doe snot
require any warning in this case
Compilers _cannot_ implicitly convert 'int* ' into 'char*' directly, meaning
that an attempt to do so would require a diagnostic.

What can be done, is that you can perform that conversion without using an
explicit cast, as a two-step process involving 'void*' as an intermediate type
'int*' -'void*' -'char*'.

int* pi;
...
void* pv = pi; /* implicit conversion 1 */
char* pc = pv; /* implicit conversion 2 */

Needless to say, due to the two-step structure of the process, in general case
the compiler cannot catch the problem here, if there's one. So, of course, it is
not surprising there's no requirement for any diagnostic.

--
Best regards,
Andrey Tarasevich
Jun 27 '08 #15
On 16 Apr 2008 at 14:37, Eric Sosman wrote:
In the particular case of thing* to or from char* it's
not ipso facto an error: C specifically permits accessing
an object's representation as an array of char.

A better example might be double* to void* to int*,
which is either an error or at best a dubious practice.
I don't see why isn't necessarily dubious. Portability isn't everything,
and in speed-critical sections of code, using bit-twiddling to
manipulate floating-point numbers can be a very valuable practice.

Jun 27 '08 #16
Eric Sosman wrote:
CBFalconer wrote:
>arnuld wrote:
>>>Jack Klein wrote:
... snip ...
>>>
To and from other object pointer type. There is no defined
conversion between pointers to functions and pointers to object
types, even incomplete object types like void.

so an int* is implicitly converted to a void* which then can be
implicitly converted to char* without any warning at all.

No, that is a programming error. That particular void* can be
converted back into an int* without loss, but other conversions
(implicit or not) are NOT guaranteed.

In the particular case of thing* to or from char* it's
not ipso facto an error: C specifically permits accessing
an object's representation as an array of char.
However having converted to char* there is no GUARANTEE that the
original int* can be recovered from the char*, although it probably
can be. The point is that such games require especial care and
treatment to avoid sneaky insects.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **
Jun 27 '08 #17
CBFalconer wrote:
Eric Sosman wrote:
>CBFalconer wrote:
>>arnuld wrote:
Jack Klein wrote:
>
... snip ...
To and from other object pointer type. There is no defined
conversion between pointers to functions and pointers to object
types, even incomplete object types like void.
so an int* is implicitly converted to a void* which then can be
implicitly converted to char* without any warning at all.
No, that is a programming error. That particular void* can be
converted back into an int* without loss, but other conversions
(implicit or not) are NOT guaranteed.
In the particular case of thing* to or from char* it's
not ipso facto an error: C specifically permits accessing
an object's representation as an array of char.

However having converted to char* there is no GUARANTEE that the
original int* can be recovered from the char*, although it probably
can be.
The guarantee is in section 6.3.2.3, paragraph 7:

"A pointer to an object or incomplete type may be
converted to a pointer to a different object or
incomplete type."

So the conversion from int* to char* is allowed.

"If the resulting pointer is not correctly aligned
for the pointed-to type, the behavior is undefined."

Not a problem, since the alignment of char is the weakest
there is.

"Otherwise, when converted back again, the result
shall compare equal to the original pointer."

There's the guarantee.
The point is that such games require especial care and
treatment to avoid sneaky insects.
Here we agree. IMHO, C programs would be better if type-
punning were more difficult -- not impossible, just not so easy
that people can do it without thinking.

--
Er*********@sun.com

Jun 27 '08 #18

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

Similar topics

20
by: pertheli | last post by:
Hello all What is the difference between Method 1 and Method 2 below? Is Method 2 safe to use? typedef short Word; typedef unsigned char Char; int nAllocSize = large number;
34
by: Richard Hunt | last post by:
I'm sorry for asking such a silly question, but I can't quite get my head around malloc. Using gcc I have always programmed in a lax C/C++ hybrid (which I suppose is actually c++). But I have...
231
by: Brian Blais | last post by:
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...
27
by: MK | last post by:
I am a newbie. Please help. The following warning is issued by gcc-3.2.2 compiler (pc Linux): ================================================================== read_raw_data.c:51: warning:...
42
by: Joris Adriaenssens | last post by:
This is my first posting, please excuse me if it is off-topic. I'm learning to program in C. It's been almost ten years I've been programming and a lot of things have changed apparently. I...
36
by: Martin Andert | last post by:
Hello, I have a question regarding malloc and free. Here my code sample: int main() { /* allocating dynamic memory for array */ int* array = (int*) malloc(5 * sizeof(int)); /* ... program...
54
by: Neo | last post by:
Hi Folks, I've a simple qestion related to dynamic memory allocation in C here is the code: #include <stdio.h> int main() {
68
by: James Dow Allen | last post by:
The gcc compiler treats malloc() specially! I have no particular question, but it might be fun to hear from anyone who knows about gcc's special behavior. Some may find this post interesting;...
24
by: Norbert Leister | last post by:
Hi NG, I've the problem, that a malloc call is not returning. <source-snip> printf("a\n"); my_pointer = (struct_pointer)malloc(struct_size); /*size 1420*/ printf("b\n"); </source-snip>
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
0
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
0
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 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 a new...

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.