RE: [jason@txt.com: Re: Problem with "chars"]

RE: [jason@txt.com: Re: Problem with "chars"]

[Alvarez Alberto-AALVARB1]

Hi all,
	i've always been a "malloc caster", so this had been good news for me.
	But i made a program and compiled it with gcc and g++, just for checking...

	My question raises after compiling a C program with g++ (g++ -v: gcc version 2.95.2 19991024 (release)) for Solaris, as i got this result:

	% g++ probo3.c
	probo3.c: In function `int main()':
	probo3.c:7: ANSI C++ forbids implicit conversion from `void *' in assignment

	while my program is this:

		#include <stdio.h>
		#include <stdlib.h>
	
		int main()
		{
		  char *aux;
		  aux=calloc(2, sizeof(char));
		}

	?Does anyone know the reason for this behaviour? I've always thought that C++ and C were almost the same at this kind of stuff.

Regards,

Alberto Alvarez Besada

Tlf.:        +34 914002155
e-mail.:   aalvarb1@motorola.com
            


> -----Original Message-----
> From: Glynn Clements [mailto:glynn.clements@virgin.net]
> Sent: miercoles, 17 de julio de 2002 20:54
> To: Jason P. Winters; eathan@otenet.gr; xlp@emtel.net.co;
> linux-c-programming@vger.kernel.org
> Subject: Re: [jason@txt.com: Re: Problem with "chars"]
> 
> 
> 
> Glynn Clements wrote:
> 
> > > If you don't cast it, you get a warning message:
> > > 
> > > tst.c: In function `foo':
> > > tst.c:17: warning: assignment makes pointer from integer 
> without a cast
> > 
> > Which should provide a clue that you forgot the prototype, which is
> > normally obtained using:
> > 
> > 	#include <stdlib.h>
> > 
> > An implicit cast between an *integer* (undeclared functions are
> > assumed to return "int") and any pointer *will* generate a warning
> > (unless the integer is a literal zero).
> > 
> > This is exactly *why* you *shouldn't cast* the result of malloc(),
> > because it will hide this problem.
> 
> In retrospect, it's worth mentioning that a more reliable approach is,
> where possible, to explictly enable warnings for undeclared 
> functions. 
> For gcc, this is controlled by the options:
> 
> `-Wimplicit-int'
>      Warn when a declaration does not specify a type.
> 
> `-Wimplicit-function-declaration'
> `-Werror-implicit-function-declaration'
>      Give a warning (or error) whenever a function is used 
> before being
>      declared.
> 
> `-Wimplicit'
>      Same as `-Wimplicit-int' and `-Wimplicit-function-'
>      `declaration'.
> 
> [Note that -Wimplicit is enabled by -Wall.]
> 
> While the "don't cast return types" rule is still useful (it shouldn't
> normally be necessary to cast return types, and may hide problems), it
> won't catch other cases (e.g. if the return value was assigned to an
> "int" variable, no warning would be generated, regardless of what the
> function actually returned).
> 
> -- 
> Glynn Clements <glynn.clements@virgin.net>
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [jason@txt.com: Re: Problem with "chars"]

[Elias Athanasopoulos]

On Thu, Jul 18, 2002 at 09:11:33AM +0200, Alvarez Alberto-AALVARB1 wrote:
> 	% g++ probo3.c
> 	probo3.c: In function `int main()':
> 	probo3.c:7: ANSI C++ forbids implicit conversion from `void *' in assignment
> 
> 	while my program is this:
> 
> 		#include <stdio.h>
> 		#include <stdlib.h>
> 	
> 		int main()
> 		{
> 		  char *aux;
> 		  aux=calloc(2, sizeof(char));
> 		}
> 
> 	?Does anyone know the reason for this behaviour? I've always thought that C++ and C were almost the same at this kind of stuff.

No they are not. C permits implicit conversion from void *, C++ forbids 
it.

All we said in this thread is relative to C programmingm *only*.

Elias

-- 
http://gnewtellium.sourceforge.net			MP3 is not a crime.	

Re: [jason@txt.com: Re: Problem with "chars"]

[Marius Nita]

On Thu, Jul 18, 2002 at 12:25:02PM +0300, Elias Athanasopoulos wrote:
> On Thu, Jul 18, 2002 at 09:11:33AM +0200, Alvarez Alberto-AALVARB1 wrote:
> > 	% g++ probo3.c
> > 	probo3.c: In function `int main()':
> > 	probo3.c:7: ANSI C++ forbids implicit conversion from `void *' in assignment
> > 
> > 	while my program is this:
> > 
> > 		#include <stdio.h>
> > 		#include <stdlib.h>
> > 	
> > 		int main()
> > 		{
> > 		  char *aux;
> > 		  aux=calloc(2, sizeof(char));
> > 		}
> > 
> > 	?Does anyone know the reason for this behaviour? I've always thought that C++ and C were almost the same at this kind of stuff.
> 
> No they are not. C permits implicit conversion from void *, C++ forbids 
> it.

Besides, why would you want to use malloc and calloc in c++ programs?
There's a reson that "new" exists. :)

> All we said in this thread is relative to C programmingm *only*.
> 
> Elias
> 
> -- 
> http://gnewtellium.sourceforge.net			MP3 is not a crime.	
> -
> To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[jason@txt.com: Re: Problem with "chars"]

[xlp]

This is Jason Winters reply, It was very usefull and My question was solved, I need to handle "strings" in my case.

thanks.

----- Forwarded message from "Jason P. Winters" <jason@txt.com> -----

From: "Jason P. Winters" <jason@txt.com>
Subject: Re: Problem with "chars"
To: xlp@emtel.net.co (xlp)
Date: Wed, 17 Jul 2002 06:45:46 -0700 (PDT)

 
> Hi C people, first of all, I'd like to thank you this mailing
> list and kernel.org project to give us a place where C programmers
> feel free to ask their questions and the support is excellent.
> I dont understand what's the way I should handle 'chars' on C. 
> I need to code a C function that returns a char, I want to do this:
> char foo();
> main(){
> 	char bar*;
> 	bar=foo();
> }

Hmmm.. Well, first, do you wish to return a single char, or a random
length of chars?  Your program kinda mixes the two, and you mention
below that you want to return a 'char', and then also mention you
want to return without a specific length.

These are two different return types.

char foo();

This returns a *single* char, always.  Just one. So your code could
have looked something like this:

main()
{
	char bar;
	bar = foo();
}

char foo
{
	char retbar;
	retbar = 'C';
	return(retbar);
}


Now, if you wish to return a random number of chars, it's called
an array.  And you'll need to return a pointer instead of a char.
So your main program could have looked like this:

char *foo();

main()
{
	char *bar;
	bar = foo();
}

Now we come to the tricky part... how to get a real string out of
foo().  You can't just do this:

char *foo()
{
	char retbar[20];
	strcpy(retbar, "Hi there!");
	return(retbar);
}

Because retbar isn't valid once you return. Local variables like that
are always created on the stack, once you return, the stack is
essentially invalidated (I mean here that it's available for reuse)
and it may or may not work, depending on when you use it again and
for what.  Bad move, that.  Causes nasty crashes when you least
expect it.

So, how do you do it?  You have to use malloc() and friends.
Your foo() routine could look something like this:

char *foo()
{
	char *retbar;
	retbar = (char *)malloc(20);
	strcpy(retbar, "Hi There!");
	return(retbar);
}

Malloc allocates a nice new set of memory on the heap, and you are
now returning the pointer to it.

NOTE!!!  In this sample code, there is NO error checking!  It's been
left out for clarity of the sample, and is NOT the way you should be
doing it!   The string "Hi There!" is obviously not something you would
bother returning, and it's only used as a point to say "copy some data
here".  A little better way to do that same routine (and the same
silly data) would be something like this:

char *foo()
{
	char *retbar;
	char *sample="Hi There!";

	if((retbar = (char *)malloc(strlen(sample)+1)) != (char *)0)
		strncpy(retbar, sample, strlen(sample));
	return(retbar);
}


So, there you have my humble offering.. hope that makes sense and
I didn't leave out *too* much (It's early here, haven't had my
coffee yet).

Ciao!

Jason
-- 
|UUCP  jason@txt.com                        Who wills, Can.
|VOICE (408) 243-3425                         Who tries, Does.
|LOCAL Hey, Jason!                              Who loves, Lives.          o_.
|Disclaimer:  Not me! I didn't do *THAT!*                                 <|
|Local Disclaimer:  I'm not here!                   A. McCaffrey           4


----- End forwarded message -----

Re: [jason@txt.com: Re: Problem with "chars"]

[Elias Athanasopoulos]

On Wed, Jul 17, 2002 at 09:33:16AM -0500, xlp wrote:
> char *foo()
> {
> 	char *retbar;
> 	retbar = (char *)malloc(20);

Although it's tend to be an aesthitic issue, it is a *good* habit to not
cast malloc().  

Elias

--
http://gnewtellium.sourceforge.net			MP3 is not a crime.	

Re: [jason@txt.com: Re: Problem with "chars"]

[Jason P. Winters]

 
> On Wed, Jul 17, 2002 at 09:33:16AM -0500, xlp wrote:
> > char *foo()
> > {
> > 	char *retbar;
> > 	retbar = (char *)malloc(20);
> 
> Although it's tend to be an aesthitic issue, it is a *good* habit to not
> cast malloc().  

Huh?  I mean, excuse me?  Where do you find a reference to _not_ casting
the output of malloc()?   Malloc returns a (void *) reference, you -need-
to cast it to the type you're assigning it as.

If you don't cast it, you get a warning message:

tst.c: In function `foo':
tst.c:17: warning: assignment makes pointer from integer without a cast


So, do we ignore the message from the compiler? 

Now, *That's* a bad habit to get into...

Ciao!

Jason
-- 
|UUCP  jason@txt.com                        Who wills, Can.
|VOICE (408) 243-3425                         Who tries, Does.
|LOCAL Hey, Jason!                              Who loves, Lives.          o_.
|Disclaimer:  Not me! I didn't do *THAT!*                                 <|
|Local Disclaimer:  I'm not here!                   A. McCaffrey           4

Re: [jason@txt.com: Re: Problem with "chars"]

[Glynn Clements]

Jason P. Winters wrote:

> > > char *foo()
> > > {
> > > 	char *retbar;
> > > 	retbar = (char *)malloc(20);
> > 
> > Although it's tend to be an aesthitic issue, it is a *good* habit to not
> > cast malloc().  
> 
> Huh?  I mean, excuse me?  Where do you find a reference to _not_ casting
> the output of malloc()?   Malloc returns a (void *) reference, you -need-
> to cast it to the type you're assigning it as.

No. Implicit casts to and from "void *" result in neither an error nor
a warning.

> If you don't cast it, you get a warning message:
> 
> tst.c: In function `foo':
> tst.c:17: warning: assignment makes pointer from integer without a cast

Which should provide a clue that you forgot the prototype, which is
normally obtained using:

	#include <stdlib.h>

An implicit cast between an *integer* (undeclared functions are
assumed to return "int") and any pointer *will* generate a warning
(unless the integer is a literal zero).

This is exactly *why* you *shouldn't cast* the result of malloc(),
because it will hide this problem.

> So, do we ignore the message from the compiler? 

No. You fix the problem about which it's warning (the lack of a
protoype), rather than simply making the warning go away without
actually fixing the problem.

On an ILP32 (int/long/pointer == 32 bits) architecture (e.g. x86), you
will get away with it. On an LP64 (long/pointer == 64 bits, int
implicitly 32 bits) architecture, the compiler will generate code on
the basis that malloc() returns 32 bits of data. But it will actually
return 64 bits (a pointer), resulting in undefined behaviour.

-- 
Glynn Clements <glynn.clements@virgin.net>

Re: [jason@txt.com: Re: Problem with "chars"]

[Jason P. Winters]

 
> > Huh?  I mean, excuse me?  Where do you find a reference to _not_ casting
> > the output of malloc()?   Malloc returns a (void *) reference, you -need-
> > to cast it to the type you're assigning it as.


> An implicit cast between an *integer* (undeclared functions are
> assumed to return "int") and any pointer *will* generate a warning
> (unless the integer is a literal zero).


> On an ILP32 (int/long/pointer == 32 bits) architecture (e.g. x86), you
> will get away with it. On an LP64 (long/pointer == 64 bits, int
> implicitly 32 bits) architecture, the compiler will generate code on
> the basis that malloc() returns 32 bits of data. But it will actually
> return 64 bits (a pointer), resulting in undefined behaviour.


Actually, ya'll are both right. :}  I went digging back into my books,
and found this passage in the back of one:

  This interpretation of void * pointers is new; previously, char * pointers
  played the role of generic pointer.  The ANSI standard specifically blesses
  the meeting of void * pointers with object pointers in assignments and
  relationals, while requiring explicit casts for other pointer mixtures.


Which will probably also give you some idea of my age, and when I
learned 'C'. :}

Thanks, one less cast I have to put in. ;}  Guess I'll wander through the
include files, and see what else is finally cast free...

Ciao!

Jason
-- 
|UUCP  jason@txt.com                        Who wills, Can.
|VOICE (408) 243-3425                         Who tries, Does.
|LOCAL Hey, Jason!                              Who loves, Lives.          o_.
|Disclaimer:  Not me! I didn't do *THAT!*                                 <|
|Local Disclaimer:  I'm not here!                   A. McCaffrey           4

Re: [jason@txt.com: Re: Problem with "chars"]

[Glynn Clements]

Glynn Clements wrote:

> > If you don't cast it, you get a warning message:
> > 
> > tst.c: In function `foo':
> > tst.c:17: warning: assignment makes pointer from integer without a cast
> 
> Which should provide a clue that you forgot the prototype, which is
> normally obtained using:
> 
> 	#include <stdlib.h>
> 
> An implicit cast between an *integer* (undeclared functions are
> assumed to return "int") and any pointer *will* generate a warning
> (unless the integer is a literal zero).
> 
> This is exactly *why* you *shouldn't cast* the result of malloc(),
> because it will hide this problem.

In retrospect, it's worth mentioning that a more reliable approach is,
where possible, to explictly enable warnings for undeclared functions. 
For gcc, this is controlled by the options:

`-Wimplicit-int'
     Warn when a declaration does not specify a type.

`-Wimplicit-function-declaration'
`-Werror-implicit-function-declaration'
     Give a warning (or error) whenever a function is used before being
     declared.

`-Wimplicit'
     Same as `-Wimplicit-int' and `-Wimplicit-function-'
     `declaration'.

[Note that -Wimplicit is enabled by -Wall.]

While the "don't cast return types" rule is still useful (it shouldn't
normally be necessary to cast return types, and may hide problems), it
won't catch other cases (e.g. if the return value was assigned to an
"int" variable, no warning would be generated, regardless of what the
function actually returned).

-- 
Glynn Clements <glynn.clements@virgin.net>

Re: [jason@txt.com: Re: Problem with "chars"]

[Elias Athanasopoulos]

On Wed, Jul 17, 2002 at 10:55:52AM -0700, Jason P. Winters wrote:
> Huh?  I mean, excuse me?  Where do you find a reference to _not_ casting
> the output of malloc()?   Malloc returns a (void *) reference, you -need-
> to cast it to the type you're assigning it as.
> 
> If you don't cast it, you get a warning message:
> 
> tst.c: In function `foo':
> tst.c:17: warning: assignment makes pointer from integer without a cast
> 
> 
> So, do we ignore the message from the compiler? 
> 
> Now, *That's* a bad habit to get into...

Pls, include stdlib.h and you'll be happy.

The C standard (call it C99, but this comes from the earlier days) states
that void * is implicitly casted to everything is on the other side.

By explicitly casting malloc() you don't get the warning you wrote, but
the correct way to vanish the warning is to include stdlib.h.

Elias

-- 
http://gnewtellium.sourceforge.net			MP3 is not a crime.	

Re: [jason@txt.com: Re: Problem with "chars"]

[Marius Nita]

On Wed, Jul 17, 2002 at 10:55:52AM -0700, Jason P. Winters wrote:
>  
> > On Wed, Jul 17, 2002 at 09:33:16AM -0500, xlp wrote:
> > > char *foo()
> > > {
> > > 	char *retbar;
> > > 	retbar = (char *)malloc(20);
> > 
> > Although it's tend to be an aesthitic issue, it is a *good* habit to not
> > cast malloc().  
> 
> Huh?  I mean, excuse me?  Where do you find a reference to _not_ casting
> the output of malloc()?   Malloc returns a (void *) reference, you -need-
> to cast it to the type you're assigning it as.

The other folks already answered this, but it's worth pointing out that W
Richard Stevens talks about this in Advanced Programming in the Unix
Environment, and points out that the return of malloc should NOT be casted,
and stdlib.h should be included to avoid warnings..

It seems that this issue has become a religious thing, tho I don't see why. It
is clear that the return of malloc need not (and must not--for correctness) be
casted.

Besides,

  struct Blah *foo = malloc( sizeof(struct Blah) );

looks a lot more readable than

  struct Blah *foo = (struct Blah *)malloc( sizeof(struct Blah) );

> If you don't cast it, you get a warning message:
> 
> tst.c: In function `foo':
> tst.c:17: warning: assignment makes pointer from integer without a cast
> 
> 
> So, do we ignore the message from the compiler? 
> 
> Now, *That's* a bad habit to get into...
> 
> Ciao!
> 
> Jason
> -- 
> |UUCP  jason@txt.com                        Who wills, Can.
> |VOICE (408) 243-3425                         Who tries, Does.
> |LOCAL Hey, Jason!                              Who loves, Lives.          o_.
> |Disclaimer:  Not me! I didn't do *THAT!*                                 <|
> |Local Disclaimer:  I'm not here!                   A. McCaffrey           4
> -
> To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [jason@txt.com: Re: Problem with "chars"]

[Earl R. Lapus]

>The other folks already answered this, but it's worth pointing out that W
>Richard Stevens talks about this in Advanced Programming in the Unix
>Environment, and points out that the return of malloc should NOT be casted,
>and stdlib.h should be included to avoid warnings..

Yeah.. p.170 =)

Re: [jason@txt.com: Re: Problem with "chars"]

[Mike Castle]

In article <20020717123023.A2248@cs.pdx.edu>,
Marius Nita  <marius@cs.pdx.edu> wrote:
>It seems that this issue has become a religious thing, tho I don't see why. It
>is clear that the return of malloc need not (and must not--for correctness) be
>casted.

I believe it was necessary for pre or early ANSI C, so a lot of old code
written by some pretty smart people used it.

mrc

-- 
     Mike Castle      dalgoda@ix.netcom.com      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

Re: [jason@txt.com: Re: Problem with "chars"]

[Jason P. Winters]

 
Mike Castle said:
> In article <20020717123023.A2248@cs.pdx.edu>,
> Marius Nita  <marius@cs.pdx.edu> wrote:
> >It seems that this issue has become a religious thing, tho I don't see why. It
> >is clear that the return of malloc need not (and must not--for correctness) be
> >casted.
> 
> I believe it was necessary for pre or early ANSI C, so a lot of old code
> written by some pretty smart people used it.

I beleive that totally.  And when you add in the fact that a lot of people
move transparently between C and C++, which still requires casting, you can
see that adding the extra casts is a common and easilly understood thing.

Which probably contributed to why I never noticed I didn't need to do it in C
anymore.. ;}

Ciao all!

Jason
-- 
|UUCP  jason@txt.com                        Who wills, Can.
|VOICE (408) 243-3425                         Who tries, Does.
|LOCAL Hey, Jason!                              Who loves, Lives.          o_.
|Disclaimer:  Not me! I didn't do *THAT!*                                 <|
|Local Disclaimer:  I'm not here!                   A. McCaffrey           4

Re: [jason@txt.com: Re: Problem with "chars"]

[Glynn Clements]

Jason P. Winters wrote:

> > >It seems that this issue has become a religious thing, tho I don't see why. It
> > >is clear that the return of malloc need not (and must not--for correctness) be
> > >casted.
> > 
> > I believe it was necessary for pre or early ANSI C, so a lot of old code
> > written by some pretty smart people used it.
> 
> I beleive that totally.  And when you add in the fact that a lot of people
> move transparently between C and C++, which still requires casting, you can
> see that adding the extra casts is a common and easilly understood thing.

Casting in C++ is anything but easily understood. Primarily due to the
fact that the correspondence between method names and methods is
controlled by an object's type, but also due to the existence of type
conversion methods.

If you get a type mismatch in C++, the *last* thing that you should do
is to simply add a cast to make the warning/error go away without
actually analysing the consequences.

Even in C, casting may affect the code which is generated, e.g. due to
alignment/packing issues, aliasing rules, non-uniform pointer
representation etc.

-- 
Glynn Clements <glynn.clements@virgin.net>