«

In <> Uno <> writes:

> char * testc() {

If testc() doesn't take any arguments, then spell it out explicitly:

char *testc(void)

> char * pa;
> pa = (char *)malloc (50);

Don't cast the return value of malloc. There's no need, and it can hide
errors later on if you change the type of pa but forget to change the
cast.

> strcpy((char *)pa, "this sentence is less than fifty bytes.");

Why are you casting pa to a char pointer when it already is one?

--
John Gordon A is for Amy, who fell down the stairs
B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

On Jul 26, 12:53*am, John Gordon <gor...@panix.com> wrote:
> * char *testc(void)
>
> > * * *char * pa;
> > * * *pa = (char *)malloc (50);
>
> Don't cast the return value of malloc. *There's no need, and it can hide
> errors later on if you change the type of pa but forget to change the
> cast.

Please don't give (distinctly debatable) style tips as if they were
hard and fast rules. Not casting malloc has both benefits and
drawbacks w.r.t. hiding bugs, and to suggest otherwise is to
demonstrate incomplete understanding.

On Jul 26, 4:50*am, gwowen <gwo...@gmail.com> wrote:
> On Jul 26, 12:53*am, John Gordon <gor...@panix.com> wrote:
>
> > * char *testc(void)
>
> > > * * *char * pa;
> > > * * *pa = (char *)malloc (50);
>
> > Don't cast the return value of malloc. *There's no need, and it can hide
> > errors later on if you change the type of pa but forget to change the
> > cast.
>
> Please don't give (distinctly debatable) style tips as if they were
> hard and fast rules. *Not casting malloc has both benefits and
> drawbacks w.r.t. hiding bugs, and to suggest otherwise is to
> demonstrate incomplete understanding.

In C you do not need to cast void* to any other pointer type.
Specifically casting it to silence warnings shows you're doing
something wrong. By default the compiler will think that malloc
returns "int" which in many cases is not the same size [or more
importantly castable] as a pointer.

I'd also point out this is something trolls question repeatedly to get
a rise out of the regulars [who aren't trolls, I'd argue the trolls
are also part of the set of regulars, just not the helpful subset].

Tom

On 07/26/2011 04:50 AM, gwowen wrote:
> On Jul 26, 12:53�am, John Gordon <gor...@panix.com> wrote:
>> � char *testc(void)
>>
>>> � � �char * pa;
>>> � � �pa = (char *)malloc (50);
>>
>> Don't cast the return value of malloc. �There's no need, and it can hide
>> errors later on if you change the type of pa but forget to change the
>> cast.
>
> Please don't give (distinctly debatable) style tips as if they were
> hard and fast rules. Not casting malloc has both benefits and
> drawbacks w.r.t. hiding bugs, and to suggest otherwise is to
> demonstrate incomplete understanding.

What are the drawbacks? I'm not familiar with any.
--
James Kuyper

In <6e8108d6-cf53-4d7c-940d-> gwowen <> writes:

> > Don't cast the return value of malloc. There's no need, and it can
> > hide errors later on if you change the type of pa but forget to change
> > the cast.

> Please don't give (distinctly debatable) style tips as if they were
> hard and fast rules. Not casting malloc has both benefits and
> drawbacks w.r.t. hiding bugs, and to suggest otherwise is to
> demonstrate incomplete understanding.

I am unaware that casting malloc has any benefits at all. Please
elaborate.

--
John Gordon A is for Amy, who fell down the stairs
B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

On Jul 26, 8:01*am, Kenneth Brody <kenbr...@spamcop.net> wrote:
> On 7/26/2011 4:50 AM, gwowen wrote:
>
> > On Jul 26, 12:53 am, John Gordon<gor...@panix.com> *wrote:
> >> * *char *testc(void)
>
> >>> * * * char * pa;
> >>> * * * pa = (char *)malloc (50);
>
> >> Don't cast the return value of malloc. *There's no need, and it can hide
> >> errors later on if you change the type of pa but forget to change the
> >> cast.
>
> > Please don't give (distinctly debatable) style tips as if they were
> > hard and fast rules. *Not casting malloc has both benefits and
> > drawbacks w.r.t. hiding bugs, and to suggest otherwise is to
> > demonstrate incomplete understanding.
>
> Please explain when, in C, there is a "benefit" to casting the return from
> malloc().
>
> Unless you are using an ancient C compiler which predates "void *", thereis
> no good reason I can think of for casting the return from malloc(). *And,
> even on those ancient systems, the return was defined as "char *", making
> the cast in the instant case redundant.
>

Let's say I'm working on a programming project that uses multiple
languages. And now let's say that the only (apparent) way I can get C
to cooperate with the other programming languages is to cast the
return value from malloc(). How would you get around avoiding casting
the return from malloc()?

Chad

In <1c6b604c-cb47-4c76-b4ca-> Chad <> writes:

> Let's say I'm working on a programming project that uses multiple
> languages. And now let's say that the only (apparent) way I can get C
> to cooperate with the other programming languages is to cast the
> return value from malloc(). How would you get around avoiding casting
> the return from malloc()?

If you're calling malloc() from within a module written in another
language, then you should use whatever mechanism that language provides
for coercing the return value of malloc() into a compatible representation.
But this isn't C casting, so this example is irrelevant.

If you're calling malloc() from within C code, the presence elsewhere in
your program of modules written in other languages is irrelevant.

In short, I don't see how other languages are relevant to this discussion.

--
John Gordon A is for Amy, who fell down the stairs
B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

On 2011-07-26, Chad <> wrote:
> On Jul 26, 8:01?am, Kenneth Brody <kenbr...@spamcop.net> wrote:
>>
>> Please explain when, in C, there is a "benefit" to casting the return from
>> malloc().
>>
>> Unless you are using an ancient C compiler which predates "void *", there is
>> no good reason I can think of for casting the return from malloc(). ?And,
>> even on those ancient systems, the return was defined as "char *", making
>> the cast in the instant case redundant.
>>
>
> Let's say I'm working on a programming project that uses multiple
> languages. And now let's say that the only (apparent) way I can get C
> to cooperate with the other programming languages is to cast the
> return value from malloc(). How would you get around avoiding casting
> the return from malloc()?

I would say that you're either doing something very wrong or your
implementation is broken.


--
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c

On Jul 26, 11:08*am, Kenneth Brody <kenbr...@spamcop.net> wrote:
> On 7/26/2011 9:17 AM, tom st denis wrote:
> [...]> In C you do not need to cast void* to any other pointer type.
> > Specifically casting it to silence warnings shows you're doing
> > something wrong. *By default the compiler will think that malloc
> > returns "int" which in many cases is not the same size [or more
> > importantly castable] as a pointer.
>
> [...]
>
> More importantly still are those platforms with separate "data" and
> "address" registers, on which a pointer value is returned on a totally
> distinct register than an integer value. *On such platforms, it's not just
> that the value it sees can't be properly cast to a pointer, but it's looking
> in the wrong place to begin with.

Also a good point ya.

Generally speaking I don't get why they insist on bringing it up over
and over. Header files took me all of no time to learn when I was
teaching myself the very basics of C when I was 10. Admittedly I
wasn't a developer then, but it wasn't exactly rocket surgery to
realize "oh wait, I need to include the definition of the function
with a header so the compiler knows how the function call works..."

Usually if I don't have it memorized I just read the man page. Takes
me three seconds to look up a C function and I'm on my way.

Oddly enough the time these people save by writing quick and dirty
code they usually lose in multiple-fold by having to debug it later...

Tom

On 2011-07-26, gwowen <> wrote:
> Please don't give (distinctly debatable) style tips as if they were
> hard and fast rules. Not casting malloc has both benefits and
> drawbacks w.r.t. hiding bugs, and to suggest otherwise is to
> demonstrate incomplete understanding.

Could you give an example of a case, in C, where not casting malloc hides
a bug that would have been caught had it been cast?

-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.