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

 
 
Seebs
Guest
Posts: n/a
 
      07-26-2011
On 2011-07-26, Chad <(E-Mail Removed)> wrote:
> Let's say I'm working on a programming project that uses multiple
> languages.


Hmm. Maybe?

> 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().


This is "begging the question"; you're simply assuming that the cast
is necessary, without showing *how* it could be necessary.

> How would you get around avoiding casting
> the return from malloc()?


By not assuming something which isn't true.

Compile C code in C. Don't compile C code in other languages. If you need
to mix C and other languages, do it by separating C and other languages into
separate hunks of code. Compile C with the C compiler, which does not need
casts for malloc. If you need to call C from another language, do so by
using whatever tools that language has for calling C.

-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / http://www.velocityreviews.com/forums/(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
 
 
 
 
Paul N
Guest
Posts: n/a
 
      07-26-2011
On Jul 26, 3:58*pm, John Gordon <(E-Mail Removed)> wrote:

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


(and James Kuyper and Kenneth Brody asked similar things)

1) As Kenneth Brody has pointed out, it means your code will work with
an ancient compiler in which malloc returns a char *.

2) It means that the code doesn't need to be re-written should you
wish to treat it as C++ code.

3) Some programmers just feel it is "wrong" to assign a value of one
type to a variable of another, and this will make them feel happier
about the code. I presume there are no program checking tools which
feel likewise, though this would help if there were.

So that's three arguable benefits, though there is obviously a strong
argument that they are outweighed by the benefits of not casting.
 
Reply With Quote
 
 
 
 
lawrence.jones@siemens.com
Guest
Posts: n/a
 
      07-26-2011
Bill Waddington <(E-Mail Removed)> wrote:
>
> Oh my. Someone who knows what "begging the question" actaully means.


There are still lots of us around, although we are greatly outnumbered.
--
Larry Jones

Hey Doc, for 10 bucks I'll make sure you see those kids in the
waiting room again real soon! -- Calvin
 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      07-27-2011
On Jul 26, 9: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.


but on balance omitting the cast is the best option. Putting an
unnecesary cast in can hide bug. I don't see how leaving out the cast
can hide bugs.

The only good reason for casting malloc that I can see is that you're
compiling K&R C or using a C++ compiler. The Dinkum people who
maintain both C and C++ libraries reckon they have justification. But
hardly anyone else has.
 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      07-27-2011
On Jul 26, 6:51*pm, tom st denis <(E-Mail Removed)> wrote:
> 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 notjust
> > 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...


I always thought it should have been an error diagnosed by the
compiler- to not have a prototype in scope.

 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      07-27-2011
On Jul 26, 10:56*pm, Paul N <(E-Mail Removed)> wrote:
> On Jul 26, 3:58*pm, John Gordon <(E-Mail Removed)> wrote:



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

>
> (and James Kuyper and Kenneth Brody asked similar things)
>
> 1) As Kenneth Brody has pointed out, it means your code will work with
> an ancient compiler in which malloc returns a char *.
>
> 2) It means that the code doesn't need to be re-written should you
> wish to treat it as C++ code.


if you're in one of those environemtns then so be it.

> 3) Some programmers just feel it is "wrong" to assign a value of one
> type to a variable of another, and this will make them feel happier
> about the code.


I'd say the programmer needed debugging...


> I presume there are no program checking tools which
> feel likewise,


if there are they should be cast into the Outer Darkness. Sounds like
a very broken lint.


> though this would help if there were.


how does a tool that generates spurious "errors" help anyone?


> So that's three arguable benefits,


two weird environments and a programwer that needs re-education

> though there is obviously a strong
> argument that they are outweighed by the benefits of not casting.


yay!

 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      07-27-2011
On 07/27/2011 02:24 AM, Gareth Owen wrote:
> James Kuyper <(E-Mail Removed)> writes:
>
>> What are the drawbacks? I'm not familiar with any.

>
> Lets look at the code (roughly) as given
>
> char *pa;
> /* yadda yadda yadda */
> .
> .
> .
> pa = (char*) malloc(50);
> .
> .
> .
> /* code that presumably assumes 50 elements in pa[] */
>
>
> Now the advice given was "if you change the type of *pa, the cast is
> wrong". So lets do that...
>
> With the cast
> -----------------------------------------------------------------------------
> int *pa;
> /* yadda yadda yadda */
> .
> .
> .
> pa = (char*) malloc(50);
> .
> .
> .
> /* code that presumably assumes 50 elements in pa[] */
> result: compiler error.
> -----------------------------------------------------------------------------
>
>
> Take the cast away
> -----------------------------------------------------------------------------
> int *pa;
> /* yadda yadda yadda */
> .
> .
> .
> pa = malloc(50);
> .
> .
> .
> /* code that presumably assumes 50 elements in pa[] */
> result: undefined behaviour unless sizeof(int) == 1
>
> The *failure* to cast malloc() has hidden a bug in *exactly* the case for
> which casting malloc() was held up as being wrong.


Well, no. If the missing cast were the the problem, then inserting an
(int*) would be the solution - in fact, the real problem would persist
even if an (int*) were inserted.

The change from (char*) to (int*) is not the solution, it's the problem.
If you have a policy of casting the value returned by malloc(), then you
have to modify the cast any time you change the type. It's a minor waste
of time, which doesn't come up very often. It would be easily
justifiable if it provided any corresponding benefit - but it provides
none. What needs to be matched up isn't the type, its the size, and you
can't do anything about that with a cast.

> Personally, when I accidentally write buggy code, I want a compiler
> error rather undefined behaviour. YMMV.


Nothing you can do in C will cause the real problem, the incorrect size
passed to malloc(), to be flagged as a compiler error. However, what you
can do is ensure that the size passed to malloc() is correct, regardless
of the type:

> Yes, I know all about the pa = malloc(50 * sizeof(*pa)) idiom, thanks,


So, in other words, you do know that the problem is not the "missing"
cast, but the argument passed to malloc().

> and I know that there *are* drawbacks to casting malloc. But my
> underlying point is correct - casting malloc() is a *style* issue, and
> only idiots argue that their style is correct and anything else is
> wrong.


There's style, and then there's functionality. Indentation is a pure
style issue; any consistently applied indentation style is workable, and
arguing over them is pointless. Unnecessarily casting the value returned
by malloc() is just a waste of time. However, passing the correct size
to malloc() is a functionality issue, not a size issue.
--
James Kuyper
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      07-27-2011
On 07/26/2011 05:56 PM, Paul N wrote:
> On Jul 26, 3:58�pm, John Gordon <(E-Mail Removed)> wrote:
>
>> I am unaware that casting malloc has any benefits at all. �Please
>> elaborate.

>
> (and James Kuyper and Kenneth Brody asked similar things)
>
> 1) As Kenneth Brody has pointed out, it means your code will work with
> an ancient compiler in which malloc returns a char *.


Yes, those compilers are ancient. The standard which changed that was
approved before the latest crop of computer programmers was even born. I
stopped worrying about compatibility with pre-standard compilers nearly
two decades ago.

> 2) It means that the code doesn't need to be re-written should you
> wish to treat it as C++ code.


True, but that's not a C issue.

> 3) Some programmers just feel it is "wrong" to assign a value of one
> type to a variable of another, and this will make them feel happier
> about the code. I presume there are no program checking tools which
> feel likewise, though this would help if there were.


If they're right, arguments supporting the idea that they're right would
be relevant; the fact that they feel that way is irrelevant. If they're
wrong, as I believe them to be, the right solution is the re-education
of or the choice of an alternative career by those programmers, not
unnecessary casts.

The whole point of using void* rather than char* (when it's appropriate
to do so) is the implicit conversions to and from other pointer types.
Making those conversions implicit simplifies code like this by not
mandating casts that don't buy any real advantage. Anyone who thinks
that's a bad idea should probably consider writing a bunch of wrapper
functions for those standard library functions which use void*. Then any
use of my_malloc() without a cast, for any purpose other than filling in
a char*, would guarantee the pointless diagnostic they crave.
--
James Kuyper
 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      07-27-2011
On Jul 27, 12:28*pm, James Kuyper <(E-Mail Removed)> wrote:
> On 07/26/2011 05:56 PM, Paul N wrote:
>
> > On Jul 26, 3:58 pm, John Gordon <(E-Mail Removed)> wrote:

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

>
> > (and James Kuyper and Kenneth Brody asked similar things)

>
> > 1) As Kenneth Brody has pointed out, it means your code will work with
> > an ancient compiler in which malloc returns a char *.

>
> Yes, those compilers are ancient. The standard which changed that was
> approved before the latest crop of computer programmers was even born. I
> stopped worrying about compatibility with pre-standard compilers nearly
> two decades ago.


I made a change to a K&R program about 12 months ago. My first time!

<snip>
 
Reply With Quote
 
Noob
Guest
Posts: n/a
 
      07-27-2011
Gareth Owen wrote:

> Lets look at the code (roughly) as given
>
> char *pa;
> pa = (char*) malloc(50);
> /* code that presumably assumes 50 elements in pa[] */


"elements" is unnecessarily vague;
pa can (only) store 50 CHARACTERS,
(whether the cast is there or not.)

> Now the advice given was "if you change the type of *pa,
> the cast is wrong". So lets do that...
>
> With the cast
>
> int *pa;
> pa = (char*) malloc(50);
> /* code that presumably assumes 50 elements in pa[] */


The problem is to assume that pa can store anything else
but 50 CHARACTERS, since that is what was requested... o_O

So you go back to the assignment, and write what?

pa = (int *) malloc(50*4); // not portable

pa = (int *) malloc(50*sizeof(int));

Why are you trying SO HARD to avoid the IDIOMATIC

pa = malloc(50 * sizeof *pa);

which doesn't require dicking around should you ever
want to modify pa's type?
 
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