malloc() and implicit cast

[arnuld]

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/

[Peter Nilsson]

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

[Richard Heathfield]

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

[CBFalconer]

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 **

[Eric Sosman]

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

[Andrey Tarasevich]

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

[Antoninus Twink]

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.

[CBFalconer]

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 **

[Eric Sosman]

CBFalconer wrote:

Eric Sosman wrote:

>CBFalconer wrote:

>>arnuld wrote:
Jack Klein wrote:
>
... snip ...
To and from other object pointer type. There is no defined
conversio n 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