Casting the return value of malloc() ?

[Tinkertim]

Hi,

I have often wondered if casting the return value of malloc() (or
friends) actually helps anything, recent threads here suggest that it
does not .. so I hope to find out.

For instance :

char *tmp = NULL;

tmp = (char *) malloc(1024);

Is there any pointing in casting the return value of malloc? I see
many people do that, but not test the result such as :

if (tmp == (char *) NULL)
.. some code about malloc() failing ...

Is there any point in casting it?

Cheers,
--Tim

[Ian Collins]

Re: Casting the return value of malloc() ?

Tinkertim wrote:

Hi,
>
I have often wondered if casting the return value of malloc() (or
friends) actually helps anything, recent threads here suggest that it
does not .. so I hope to find out.
>
For instance :
>
char *tmp = NULL;
>
tmp = (char *) malloc(1024);
>
Is there any pointing in casting the return value of malloc?

None what so ever.

--
Ian Collins.

[Kenny McCormack]

Re: Casting the return value of malloc() ?

In article <7ce1a426-30ed-47ee-bd72-67116099d74a@p4 9g2000hsd.googl egroups.com>,
Tinkertim <tinkertim@gmai l.comwrote:

>Hi,
>
>I have often wondered if casting the return value of malloc() (or
>friends) actually helps anything, recent threads here suggest that it
>does not .. so I hope to find out.

Good to see we're back on familiar ground.

[Richard Heathfield]

Re: Casting the return value of malloc() ?

Tinkertim said:

Hi,
>
I have often wondered if casting the return value of malloc() (or
friends) actually helps anything,

What help do you think it offers? I can't think of any.

recent threads here suggest that it
does not .. so I hope to find out.
>
For instance :
>
char *tmp = NULL;
>
tmp = (char *) malloc(1024);
>
Is there any pointing in casting the return value of malloc?

It seems completely pointless to me. Do you have any reason for doing it?

I see
many people do that, but not test the result such as :
>
if (tmp == (char *) NULL)
.. some code about malloc() failing ...
>
Is there any point in casting it?

Not that I can think of. Testing the return value, on the other hand, is
crucial.

I suggest you find someone who advocates the cast, and ask them why. Most
likely, they won't know. In the event that you find someone who does know
why they're casting, why not present this group with the reason he or she
gives you, and ask us what we think of it?

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

[Nick Keighley]

Re: Casting the return value of malloc() ?

On 2 Oct, 10:22, Tinkertim <tinker...@gmai l.comwrote:

Hi,
>
I have often wondered if casting the return value of malloc() (or
friends) actually helps anything, recent threads here suggest that it
does not .. so I hope to find out.
>
For instance :
>
char *tmp = NULL;
>
tmp = (char *) malloc(1024);
>
Is there any pointing in casting the return value of malloc? I see
many people do that, but not test the result such as :
>
if (tmp == (char *) NULL)
   .. some code about malloc() failing ...
>
Is there any point in casting it?

This is a FAQ
FAQ 7.7b "What's wrong with casting malloc's return value?"

the FAQ lives at http://c-faq.com

C++ requires a cast on the return of malloc(). But malloc()
is unusual in C++ code (an implementation of C++ might need it).
Some people write code that is required to compile under both C and
C++ (eg. library writers). They also might want to cast the return
value of malloc().


--
Nick Keighley

"Those are my principles. If you don't like them, I have others."
- Groucho Marx

[polas]

Re: Casting the return value of malloc() ?

On 2 Oct, 10:59, Nick Keighley <nick_keighley_ nos...@hotmail. com>
wrote:

On 2 Oct, 10:22, Tinkertim <tinker...@gmai l.comwrote:
>
>
>

Hi,

>

I have often wondered if casting the return value of malloc() (or
friends) actually helps anything, recent threads here suggest that it
does not .. so I hope to find out.

>

For instance :

>

char *tmp = NULL;

>

tmp = (char *) malloc(1024);

>

Is there any pointing in casting the return value of malloc? I see
many people do that, but not test the result such as :

>

if (tmp == (char *) NULL)
.. some code about malloc() failing ...

>

Is there any point in casting it?

>
This is a FAQ
FAQ 7.7b "What's wrong with casting malloc's return value?"
>
the FAQ lives athttp://c-faq.com
>
C++ requires a cast on the return of malloc(). But malloc()
is unusual in C++ code (an implementation of C++ might need it).
Some people write code that is required to compile under both C and
C++ (eg. library writers). They also might want to cast the return
value of malloc().
>

As far as I understood it (which might be somewhat wrong) actually
casting the return value is unwanted. Am I wrong that without
including stdlib.h the return value is int (or int * cant remember
which exactly) from malloc and so not casting the return value will
provide a warning/error during compilation if you have missed this
header? Whereas casting the value will hide this problem and result in
strange behaviour

Nick

--------
Mesham Parallel Programming Language

https://www.mesham.net

[Richard Heathfield]

Re: Casting the return value of malloc() ?

polas said:

<snip>

As far as I understood it (which might be somewhat wrong) actually
casting the return value is unwanted.

If you mean "unnecessar y", you're right.

Am I wrong that without
including stdlib.h the return value is int (or int * cant remember
which exactly) from malloc

In C90, whenever the compiler encounters any call to any function for which
it has not yet seen a declaration, it is required to assume that the
function returns int, even if We Know Different. (And indeed even if the
compiler knows different, which it is allowed to but not required to.)

Since you're assigning the value returned by malloc to a pointer object,
omitting the header therefore gives a type mismatch between int and
pointer, which the compiler is obliged to diagnose - UNLESS you foolishly
cast the diagnosis away.

If pointers are returned in a different way to ints, or if pointers are
longer than ints, or have completely different representations , this can
cause a very real problem.

and so not casting the return value will
provide a warning/error during compilation if you have missed this
header? Whereas casting the value will hide this problem and result in
strange behaviour

Yes, that's almost right - casting the value will hide the problem and
*may* result in strange behaviour. Or it may not. Until your boss is
watching...

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

[polas]

Re: Casting the return value of malloc() ?

On 2 Oct, 13:12, Richard Heathfield <r...@see.sig.i nvalidwrote:

polas said:
>
<snip>
>

As far as I understood it (which might be somewhat wrong) actually
casting the return value is unwanted.

>
If you mean "unnecessar y", you're right.
>

Am I wrong that without
including stdlib.h the return value is int (or int * cant remember
which exactly) from malloc

>
In C90, whenever the compiler encounters any call to any function for which
it has not yet seen a declaration, it is required to assume that the
function returns int, even if We Know Different. (And indeed even if the
compiler knows different, which it is allowed to but not required to.)
>
Since you're assigning the value returned by malloc to a pointer object,
omitting the header therefore gives a type mismatch between int and
pointer, which the compiler is obliged to diagnose - UNLESS you foolishly
cast the diagnosis away.
>
If pointers are returned in a different way to ints, or if pointers are
longer than ints, or have completely different representations , this can
cause a very real problem.
>

and so not casting the return value will
provide a warning/error during compilation if you have missed this
header? Whereas casting the value will hide this problem and result in
strange behaviour

>
Yes, that's almost right - casting the value will hide the problem and
*may* result in strange behaviour. Or it may not. Until your boss is
watching...
>
--
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

Right, thanks for the help clearing that one up for me :)

Nick
-----
Mesham Parallel Programming Language

https://www.mesham.net

[Nick Keighley]

Re: Casting the return value of malloc() ?

On 2 Oct, 12:42, polas <n...@helpforce .comwrote:

On 2 Oct, 10:59, Nick Keighley <nick_keighley_ nos...@hotmail. com>
wrote:

On 2 Oct, 10:22, Tinkertim <tinker...@gmai l.comwrote:

I have often wondered if casting the return value of malloc() (or
friends) actually helps anything, recent threads here suggest that it
does not .. so I hope to find out.

>

For instance :

>

char *tmp = NULL;

>

tmp = (char *) malloc(1024);

>

Is there any pointing in casting the return value of malloc? I see
many people do that, but not test the result such as :

>

if (tmp == (char *) NULL)
.. some code about malloc() failing ...

>

Is there any point in casting it?

>

This is a FAQ
FAQ 7.7b "What's wrong with casting malloc's return value?"

>

the FAQ lives athttp://c-faq.com

>

C++ requires a cast on the return of malloc(). But malloc()
is unusual in C++ code (an implementation of C++ might need it).
Some people write code that is required to compile under both C and
C++ (eg. library writers). They also might want to cast the return
value of malloc().

and note the "C++" in my answer. C and C++ are different langauges
and the rules are slightly different. The C++ rules may in some
slightly obscure cases lead to C being written to C++ rules.

As far as I understood it (which might be somewhat wrong) actually
casting the return value is unwanted. Am I wrong that without
including stdlib.h the return value is int (or int * cant remember
which exactly)

int

from malloc and so not casting the return value will
provide a warning/error during compilation if you have missed this
header? Whereas casting the value will hide this problem and result in
strange behaviour

yes

--
Nick Keighley

[Peter Nilsson]

Re: Casting the return value of malloc() ?

Tinkertim <tinker...@gmai l.comwrote:

I have often wondered if casting the return value
of malloc() (or friends) actually helps anything,
...

You should first define what you mean by 'help', then
ask the more basic question of whether casts help
anything period.

--
Peter

[Kenny McCormack]

Re: Casting the return value of malloc() ?

In article <8be39e8f-ccd3-4a22-9c6b-b8b17adf53a5@k3 0g2000hse.googl egroups.com>,
Nick Keighley <nick_keighley_ nospam@hotmail. comwrote some good stuff,
leading up to:
....

>An example of someone who writes code that compiles with both
>C and C++ is P.J.Plauger. Is he an imbecile or an idiot?
>
>you are on the verge of a plonk

I'm not sure who is the better archetype of the senile old fool: CBF or
McBush.

[Old Wolf]

Re: Casting the return value of malloc() ?

On Oct 3, 10:27 pm, Nick Keighley <nick_keighley_ nos...@hotmail. com>
wrote:

Yes C and C++ are different. But you can write a programs
using a LARGE subset of C that will compile with C and C++.
I know it is unfashionable to say this in clc.
But it is none the less true.

The question is, why would you want to do this?

You can write programs that compile in both C
and Fortran. But again, why would you?

Here's the reasons I can think of:
1) For curiosity's sake
2) You are an idiot

What's your reason?

[Malcolm McLean]

Re: Casting the return value of malloc() ?


"Old Wolf" <oldwolf@inspir e.net.nzwrote in message
On Oct 3, 10:27 pm, Nick Keighley <nick_keighley_ nos...@hotmail. com>
wrote:

>Yes C and C++ are different. But you can write a programs
>using a LARGE subset of C that will compile with C and C++.
>I know it is unfashionable to say this in clc.
>But it is none the less true.

>The question is, why would you want to do this?

>You can write programs that compile in both C
>and Fortran. But again, why would you?

>Here's the reasons I can think of:
1) For curiosity's sake
2) You are an idiot
>
What's your reason?
>

Programs in the common subset of Fortran and C are fit only for the
international obfuscated C competition. Rules may even allow submission to
the Fortran equivalent at the same time.

Now one good question is why use C at all when C++ is a near as makes no
difference a superset of it? However let's say that we decide that we want
to discourage people from using object-orientation, because of certain
drawbacks we see in the methodogy. A politically effective way of doing this
is to ban C++.

OK, so here's a fragment of our C program

void encrypt(unsigne d char *data, size_t len)
{
int i;

for(i=0;i<len;i ++)
data ^= 0xCC;
}

A few weeks later, the terrible news come through. Our encryption has been
compromised. We need a beter method, and fast.

So we dust off our Sedgewick and realise that there is somethign called the
RSA cryptosystem. This is very much better, and it is not too difficult to
implment, as long as you have a huge integer library. Well we've got one,
but it's in C++.

No problem. Change the file extension to .cpp, and drop in

void encrypt(unsigne d char *data, size_t len)
{
bignum prime1(13);
bignum prime2(17);
bignum unfactorisable = prime1 * prime2;

/* (etc) */
}

Now we're back in business. Nothing else needs to be changed. We've dropped
in an emergency C++ bignum library and the code is now C++ and won't compile
under C, but that is small price for turning out our improved encryption on
time.

--
Free games and programming goodies.

http://www.personal.leeds.ac.uk/~bgy1mm

[Keith Thompson]

Re: Casting the return value of malloc() ?

Old Wolf <oldwolf@inspir e.net.nzwrites:

On Oct 3, 10:27 pm, Nick Keighley <nick_keighley_ nos...@hotmail. com>
wrote:

>Yes C and C++ are different. But you can write a programs
>using a LARGE subset of C that will compile with C and C++.
>I know it is unfashionable to say this in clc.
>But it is none the less true.

>
The question is, why would you want to do this?
>
You can write programs that compile in both C
and Fortran. But again, why would you?
>
Here's the reasons I can think of:
1) For curiosity's sake
2) You are an idiot
>
What's your reason?

As we've mentioned several times in this thread, P.J. Plauger seems to
have sound business reasons for doing this. He's posted about it
here; Google it.

--
Keith Thompson (The_Other_Keit h) kst-u@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"

[Ian Collins]

Re: Casting the return value of malloc() ?

Old Wolf wrote:

On Oct 3, 10:27 pm, Nick Keighley <nick_keighley_ nos...@hotmail. com>
wrote:

>Yes C and C++ are different. But you can write a programs
>using a LARGE subset of C that will compile with C and C++.
>I know it is unfashionable to say this in clc.
>But it is none the less true.

>
The question is, why would you want to do this?
>
You can write programs that compile in both C
and Fortran. But again, why would you?
>
Here's the reasons I can think of:
1) For curiosity's sake
2) You are an idiot
>

3) Testing/Simulation.

The first C code I ever built C as C++ as a device driver. In C,
hardware registers were typedefs to an integer type. In C++ the
register types were classes that simulated the hardware behaviour when
read a written. I still use this technique today for testing drivers.

We also compiled application code as C++ to get stricter type checking,
but C compilers and lint have improved considerably in this area.

--
Ian Collins.