Type-casting void pointers?

**Alexei A. Frounze** · Nov 15 '05, 12:46 AM

Re: Type-casting void pointers?

"hugo2" <obrhy8@yahoo.c om> wrote in message
news:1121462813 .314663.11550@z 14g2000cwz.goog legroups.com...[color=blue]
> Obrhy/hugo July 12, 2004
>
> Take a look at this memcpy() definition.
> Is there a good reason the void pointer
> args are cast to byte just to assign their
> addresses to byte pointers?
>
> /*from Steve Maguire's 'Writing Soild Code'*/
>
> void *memcpy(void *pvTo,void *pvFrom,size_t size)
> {
> byte *pbTo = (byte *)pvTo;
> byte *pbFrom = (byte *)pvFrom;
> while(size-- >0)
> *pbTo++ = *pbFrom++;
>
> return (pvTo);
> }
>
> The addresses are all unsigned int. Why not
> simply byte *pbTo = pvTo; to initialize?[/color]

IMO there's no need in this if those are void*.
And unless someone's Clib implementation is broken, size_t is a nonnegative
type, hence no need to put size-->0, simply size would do.
I've seen ssize_t somewhere in linux recently, even in the single unix spec.
Stupid thing IMO. It limits the valid range by allowing signed values asking
for problems...

Alex

**Michael Mair** · Nov 15 '05, 12:46 AM

Re: Type-casting void pointers?

hugo2 wrote:[color=blue]
> Obrhy/hugo July 12, 2004
>
> Take a look at this memcpy() definition.
> Is there a good reason the void pointer
> args are cast to byte just to assign their
> addresses to byte pointers?
>
> /*from Steve Maguire's 'Writing Soild Code'*/[/color]

Did you forget an 'e' or get wrong the order of 'i'
and 'l'? SCNR
[color=blue]
> void *memcpy(void *pvTo,void *pvFrom,size_t size)
> {
> byte *pbTo = (byte *)pvTo;
> byte *pbFrom = (byte *)pvFrom;
> while(size-- >0)
> *pbTo++ = *pbFrom++;
>
> return (pvTo);
> }
>
> The addresses are all unsigned int. Why not
> simply byte *pbTo = pvTo; to initialize?[/color]

In the case of void*, the cast is completely unnecessary.
I do not know the definition of the type "byte" but if
it is anything other than a typedef for "unsigned char", I would
suggest that you have a look at the wisdom to be found in
c.l.c rather than believing this book: Unnecessary casts
are a Bad Thing.

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

**Default User** · Nov 15 '05, 12:46 AM

Re: Type-casting void pointers?

hugo2 wrote:
[color=blue]
> Obrhy/hugo July 12, 2004
>
> Take a look at this memcpy() definition.
> Is there a good reason the void pointer
> args are cast to byte just to assign their
> addresses to byte pointers?
>
> /*from Steve Maguire's 'Writing Soild Code'*/
>
> void *memcpy(void *pvTo,void *pvFrom,size_t size)
> {
> byte *pbTo = (byte *)pvTo;
> byte *pbFrom = (byte *)pvFrom;
> while(size-- >0)
> *pbTo++ = *pbFrom++;
>
> return (pvTo);
> }
>
> The addresses are all unsigned int. Why not
> simply byte *pbTo = pvTo; to initialize?[/color]

You are correct, the cast is not required in C. It would be in C++, so
that could be reason for that usage. It's similar to the casts for the
returns from the *alloc() family, not necessary but a LOT of code
examples out there do it anyway. I don't know anything about that book
you mention.

Brian

**pete** · Nov 15 '05, 12:46 AM

Re: Type-casting void pointers?

hugo2 wrote:[color=blue]
>
> Obrhy/hugo July 12, 2004
>
> Take a look at this memcpy() definition.
> Is there a good reason the void pointer
> args are cast to byte just to assign their
> addresses to byte pointers?[/color]

No.
[color=blue]
> /*from Steve Maguire's 'Writing Soild Code'*/
>
> void *memcpy(void *pvTo,void *pvFrom,size_t size)
> {
> byte *pbTo = (byte *)pvTo;
> byte *pbFrom = (byte *)pvFrom;
> while(size-- >0)
> *pbTo++ = *pbFrom++;
>
> return (pvTo);
> }
>
> The addresses are all unsigned int.[/color]

What do you mean by that?
I don't see any code about "unsigned int".
"byte" either means "unsigned char" or the definition is wrong.
memcpy works on objects of all types.
[color=blue]
> Why not simply byte *pbTo = pvTo; to initialize?[/color]

Sure.
Also, the parameter types are wrong.
There should be a const qualifier in front of void *pvFrom,
and if it were there,
then who knows if Steve Maguire's intention
would be to cast the qualifier away or not?

I'm also not to crazy about the "byte" typedef or macro,
which ever it is.

--
pete

**Keith Thompson** · Nov 15 '05, 12:46 AM

Re: Type-casting void pointers?

"hugo2" <obrhy8@yahoo.c om> writes:
[snip][color=blue]
> The addresses are all unsigned int.[/color]
[snip]

Are you assuming that an address is represented as an unsigned int?
If so, that assumption is neither correct nor necessary. An address
is an address. Addresses/pointers can be converted to and from
integer types, but there are very few guarantees about the results.
And I've worked on machines where unsigned int is 32 bits and pointers
are 64 bits.

A conforming implementation could implement pointers as fixed-length
strings that give instructions, in English, for retrieving the
referenced object ("1st memory board, 3rd chip on the left, 7th word").

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

**hugo2** · Nov 15 '05, 12:47 AM

Re: Type-casting void pointers?

Alexei A. Frounze wrote:[color=blue]
> "hugo2" <obrhy8@yahoo.c om> wrote in message
> news:1121462813 .314663.11550@z 14g2000cwz.goog legroups.com...[color=green]
> > Obrhy/hugo July 12, 2004
> >
> > Take a look at this memcpy() definition.
> > Is there a good reason the void pointer
> > args are cast to byte just to assign their
> > addresses to byte pointers?
> >
> > /*from Steve Maguire's 'Writing Soild Code'*/
> >
> > void *memcpy(void *pvTo,void *pvFrom,size_t size)
> > {
> > byte *pbTo = (byte *)pvTo;
> > byte *pbFrom = (byte *)pvFrom;
> > while(size-- >0)
> > *pbTo++ = *pbFrom++;
> >
> > return (pvTo);
> > }
> >
> > The addresses are all unsigned int. Why not
> > simply byte *pbTo = pvTo; to initialize?[/color]
>
> IMO there's no need in this if those are void*.
> And unless someone's Clib implementation is broken, size_t is a nonnegative
> type, hence no need to put size-->0, simply size would do.
> I've seen ssize_t somewhere in linux recently, even in the single unix spec.
> Stupid thing IMO. It limits the valid range by allowing signed values asking
> for problems...
>
> Alex[/color]
[color=blue]
>From hugo, July 16, 2005[/color]
Mr Alex, I think, took a space out of size-- >0
After first seeing it, I read "subtract 1 from size
and compare to 0, greater? do while... subtract 1
form size, compare to 0, and so on.

hugo-------

**Alexei A. Frounze** · Nov 15 '05, 12:47 AM

Re: Type-casting void pointers?

"hugo2" <obrhy8@yahoo.c om> wrote in message
news:1121549197 .032790.196980@ o13g2000cwo.goo glegroups.com.. .
....[color=blue][color=green][color=darkred]
> > > void *memcpy(void *pvTo,void *pvFrom,size_t size)
> > > {
> > > byte *pbTo = (byte *)pvTo;
> > > byte *pbFrom = (byte *)pvFrom;
> > > while(size-- >0)
> > > *pbTo++ = *pbFrom++;
> > >
> > > return (pvTo);
> > > }
> > >
> > > The addresses are all unsigned int. Why not
> > > simply byte *pbTo = pvTo; to initialize?[/color]
> >
> > IMO there's no need in this if those are void*.
> > And unless someone's Clib implementation is broken, size_t is a[/color][/color]
nonnegative[color=blue][color=green]
> > type, hence no need to put size-->0, simply size would do.
> > I've seen ssize_t somewhere in linux recently, even in the single unix[/color][/color]
spec.[color=blue][color=green]
> > Stupid thing IMO. It limits the valid range by allowing signed values[/color][/color]
asking[color=blue][color=green]
> > for problems...
> >
> > Alex[/color]
>[color=green]
> >From hugo, July 16, 2005[/color]
> Mr Alex, I think, took a space out of size-- >0
> After first seeing it, I read "subtract 1 from size
> and compare to 0, greater? do while... subtract 1
> form size, compare to 0, and so on.[/color]

Yeah, I obviously meant this:
....
while(size--)
....
No need to check for the sign, just for 0. If we code way too solid (I'd
rather say overdefensively ), we may end up in a clinic for psychos with a
diagnosis of multiple phobias :)

Alex

**Stephan Hoffmann** · Nov 15 '05, 12:48 AM

Re: Type-casting void pointers?

Default User wrote:
[color=blue]
> hugo2 wrote:
>[color=green]
>> Obrhy/hugo July 12, 2004
>>
>> Take a look at this memcpy() definition.
>> Is there a good reason the void pointer
>> args are cast to byte just to assign their
>> addresses to byte pointers?
>>
>> /*from Steve Maguire's 'Writing Soild Code'*/
>>
>> void *memcpy(void *pvTo,void *pvFrom,size_t size)
>> {
>> byte *pbTo = (byte *)pvTo;
>> byte *pbFrom = (byte *)pvFrom;
>> while(size-- >0)
>> *pbTo++ = *pbFrom++;
>>
>> return (pvTo);
>> }
>>
>> The addresses are all unsigned int. Why not
>> simply byte *pbTo = pvTo; to initialize?[/color]
>
>
> You are correct, the cast is not required in C. It would be in C++, so
> that could be reason for that usage. It's similar to the casts for the
> returns from the *alloc() family, not necessary but a LOT of code
> examples out there do it anyway. I don't know anything about that book
> you mention.[/color]

I think some compilers give a warning without the explicit cast.
Maybe the author wanted to write 'warning-free' code.

Stephan

**CBFalconer** · Nov 15 '05, 12:48 AM

Re: Type-casting void pointers?

Stephan Hoffmann wrote:[color=blue]
> Default User wrote:[color=green]
>> hugo2 wrote:[color=darkred]
>>> Obrhy/hugo July 12, 2004
>>>
>>> Take a look at this memcpy() definition.
>>> Is there a good reason the void pointer
>>> args are cast to byte just to assign their
>>> addresses to byte pointers?
>>>
>>> /*from Steve Maguire's 'Writing Soild Code'*/
>>>
>>> void *memcpy(void *pvTo,void *pvFrom,size_t size)
>>> {
>>> byte *pbTo = (byte *)pvTo;
>>> byte *pbFrom = (byte *)pvFrom;
>>> while(size-- >0)
>>> *pbTo++ = *pbFrom++;
>>>
>>> return (pvTo);
>>> }
>>>
>>> The addresses are all unsigned int. Why not
>>> simply byte *pbTo = pvTo; to initialize?[/color]
>>
>> You are correct, the cast is not required in C. It would be in
>> C++, so that could be reason for that usage. It's similar to the
>> casts for the returns from the *alloc() family, not necessary but
>> a LOT of code examples out there do it anyway. I don't know
>> anything about that book you mention.[/color]
>
> I think some compilers give a warning without the explicit cast.
> Maybe the author wanted to write 'warning-free' code.[/color]

If a warning appears it is because it is needed. Useless casts
serve only to preserve programming errors.

--
"If you want to post a followup via groups.google.c om, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

**Richard Heathfield** · Nov 15 '05, 12:48 AM

Re: Type-casting void pointers?

CBFalconer wrote:
[color=blue]
> Stephan Hoffmann wrote:[color=green]
>>
>> I think some compilers give a warning without the explicit cast.[/color][/color]

If so, it's a lousy warning.
[color=blue][color=green]
>> Maybe the author wanted to write 'warning-free' code.[/color][/color]

Writing bad code to avoid lousy warnings is a lousy idea. Sometimes, we do
it anyway, I know - but we should do so in the full knowledge that it's a
lousy idea, and we should feel guilty for weeks afterwards. Or even months.

[color=blue]
> If a warning appears it is because it is needed.[/color]

Would that that were the case! Some compilers diagnose perfectly good,
idiomatic, ordinary C code. Grrr.

[color=blue]
> Useless casts serve only to preserve programming errors.[/color]

Well, no; they certainly do preserve programming errors, but they can /also/
serve to cut down the diagnostics count.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

mail: rjh at above domain

**Chris Croughton** · Nov 15 '05, 12:48 AM

Re: Type-casting void pointers?

On Sun, 17 Jul 2005 05:53:51 +0000 (UTC), Richard Heathfield
<invalid@addres s.co.uk.invalid > wrote:
[color=blue]
> CBFalconer wrote:
>[color=green]
>> Stephan Hoffmann wrote:[color=darkred]
>>>
>>> I think some compilers give a warning without the explicit cast.[/color][/color]
>
> If so, it's a lousy warning.[/color]

Yup. There are some lousy compilers out there.
[color=blue][color=green][color=darkred]
>>> Maybe the author wanted to write 'warning-free' code.[/color][/color]
>
> Writing bad code to avoid lousy warnings is a lousy idea. Sometimes, we do
> it anyway, I know - but we should do so in the full knowledge that it's a
> lousy idea, and we should feel guilty for weeks afterwards. Or even months.[/color]

I do, but it's a job requirement (specifically, we don't get to choose
the compiler, that's determined by what the customer is using, and
delivering code with hundreds of warnings is not good for business).
[color=blue][color=green]
>> If a warning appears it is because it is needed.[/color]
>
> Would that that were the case! Some compilers diagnose perfectly good,
> idiomatic, ordinary C code. Grrr.[/color]

Indeed. while(1) is a common case, as is assigning an integer value to
a smaller type ("char ch = (val % 10) + '0';"). The big problem is that
such warnings, while they may indicate mistakes, more often obscure the
real diagnostics (on some compilers I've had so many warnings about
perfectly good code that I couldn't even find the fatal errors).
[color=blue][color=green]
>> Useless casts serve only to preserve programming errors.[/color]
>
> Well, no; they certainly do preserve programming errors, but they can /also/
> serve to cut down the diagnostics count.[/color]

The cast, where it is obvious, can also be used as documentation: "Yes,
I really do mean to put an int into a characters variable dammit!".

In particular, I've never come across any case in professional
programming where casting malloc() (or other void pointer) actually
masked a failure to declare it or include the relevant header file,
whereas I have come across cases where:

pointer = (my_type*) malloc(sizeof(m y_type));

correctly pointed out that the type of the pointer was not the same as
expected, whereas just assigning the void pointer wouldn't have created
any diagnostic at all.

Chris C

**Keith Thompson** · Nov 15 '05, 12:48 AM

Re: Type-casting void pointers?

Chris Croughton <chris@keristor .net> writes:
[...][color=blue]
> In particular, I've never come across any case in professional
> programming where casting malloc() (or other void pointer) actually
> masked a failure to declare it or include the relevant header file,
> whereas I have come across cases where:
>
> pointer = (my_type*) malloc(sizeof(m y_type));
>
> correctly pointed out that the type of the pointer was not the same as
> expected, whereas just assigning the void pointer wouldn't have created
> any diagnostic at all.[/color]

Which is why the recommended idiom is

pointer = malloc(sizeof *pointer);

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

**pete** · Nov 15 '05, 12:48 AM

Re: Type-casting void pointers?

Chris Croughton wrote:
[color=blue]
> In particular, I've never come across any case in professional
> programming where casting malloc() (or other void pointer) actually
> masked a failure to declare it or include the relevant header file,
> whereas I have come across cases where:
>
> pointer = (my_type*) malloc(sizeof(m y_type));
>
> correctly pointed out that the type of the pointer was not the same as
> expected,
> whereas just assigning the void pointer wouldn't have created
> any diagnostic at all.[/color]

If pointer points to type mytype, or even if not,
then the clc idiomatic way:
pointer = malloc(sizeof *pointer);
seems best to me.

If pointer points to type void,
then my preference is to locate in the code,
an object identifier with the appropriate type and use that.

tail -> data = malloc(sizeof object);

*(struct oobject *)tail -> data = object;

For sizeof based arguments in a malloc call,
my preference is always sizeof object_identifi er, never sizeof(type).

--
pete

**Tim Woodall** · Nov 15 '05, 12:48 AM

Re: Type-casting void pointers?

On Sun, 17 Jul 2005 09:43:49 +0100,
Chris Croughton <chris@keristor .net> wrote:[color=blue]
>
> In particular, I've never come across any case in professional
> programming where casting malloc() (or other void pointer) actually
> masked a failure to declare it or include the relevant header file,
> whereas I have come across cases where:
>[/color]
In my last job when we first ported to some of the 64 bit architectures
we found a few dozen places like this where the cast of malloc had
masked the warning (and the code didn't work with 32bit ints, 64 bit
pointers)

Tim.

--
God said, "div D = rho, div B = 0, curl E = - @B/@t, curl H = J + @D/@t,"
and there was light.

http://tjw.hn.org/ http://www.locofungus.btinternet.co.uk/

Type-casting void pointers?

Type-casting void pointers?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment