Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: is there anything unstandard in the c part here

Reply
Thread Tools

Re: is there anything unstandard in the c part here

 
 
John Gordon
Guest
Posts: n/a
 
      07-25-2011
In <(E-Mail Removed)> Uno <(E-Mail Removed)> 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
http://www.velocityreviews.com/forums/(E-Mail Removed) B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

 
Reply With Quote
 
 
 
 
gwowen
Guest
Posts: n/a
 
      07-26-2011
On Jul 26, 12:53*am, John Gordon <(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
 
tom st denis
Guest
Posts: n/a
 
      07-26-2011
On Jul 26, 4:50*am, gwowen <(E-Mail Removed)> wrote:
> On Jul 26, 12:53*am, John Gordon <(E-Mail Removed)> 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
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      07-26-2011
On 07/26/2011 04:50 AM, gwowen wrote:
> On Jul 26, 12:53�am, John Gordon <(E-Mail Removed)> 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
 
Reply With Quote
 
John Gordon
Guest
Posts: n/a
 
      07-26-2011
In <(E-Mail Removed)> gwowen <(E-Mail Removed)> 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
(E-Mail Removed) B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

 
Reply With Quote
 
Chad
Guest
Posts: n/a
 
      07-26-2011
On Jul 26, 8:01*am, Kenneth Brody <(E-Mail Removed)> wrote:
> On 7/26/2011 4:50 AM, gwowen wrote:
>
> > On Jul 26, 12:53 am, John Gordon<(E-Mail Removed)> *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
 
Reply With Quote
 
John Gordon
Guest
Posts: n/a
 
      07-26-2011
In <(E-Mail Removed)> Chad <(E-Mail Removed)> 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
(E-Mail Removed) B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

 
Reply With Quote
 
Angel
Guest
Posts: n/a
 
      07-26-2011
On 2011-07-26, Chad <(E-Mail Removed)> wrote:
> On Jul 26, 8:01?am, Kenneth Brody <(E-Mail Removed)> 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
 
Reply With Quote
 
tom st denis
Guest
Posts: n/a
 
      07-26-2011
On Jul 26, 11:08*am, Kenneth Brody <(E-Mail Removed)> 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
 
Reply With Quote
 
Seebs
Guest
Posts: n/a
 
      07-26-2011
On 2011-07-26, gwowen <(E-Mail Removed)> 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 / (E-Mail Removed)
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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: is there anything unstandard in the c part here Nick Keighley C Programming 16 08-01-2011 03:20 PM
Re: is there anything unstandard in the c part here Barry Schwarz C Programming 11 07-27-2011 06:10 PM
Does anyone Here know anything about when Digtial phones will bereleased David S. Computer Support 13 08-12-2005 03:28 AM
ActiveX apologetic Larry Seltzer... "Sun paid for malicious ActiveX code, and Firefox is bad, bad bad baad. please use ActiveX, it's secure and nice!" (ok, the last part is irony on my part) fernando.cassia@gmail.com Java 0 04-16-2005 10:05 PM



Advertisments