Type-casting void pointers?

[hugo2]

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?

hugo ---------

[Alexei A. Frounze]

"hugo2" <ob****@yahoo.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...

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?

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]

hugo2 wrote:

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'*/
Did you forget an 'e' or get wrong the order of 'i'
and 'l'? SCNR
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?

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]

hugo2 wrote:

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?

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]

hugo2 wrote:

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?
No.
/*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.
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.
Why not simply byte *pbTo = pvTo; to initialize?

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]

"hugo2" <ob****@yahoo.com> writes:
[snip]

The addresses are all unsigned int.

[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_Keith) ks***@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]

Alexei A. Frounze wrote:

"hugo2" <ob****@yahoo.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...

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

From hugo, July 16, 2005

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]

"hugo2" <ob****@yahoo.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
....

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?

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

From hugo, July 16, 2005

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.

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]

Default User wrote:

hugo2 wrote:

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?

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.

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

Stephan

[CBFalconer]

Stephan Hoffmann wrote:

Default User wrote:

hugo2 wrote:

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?

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.

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

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.com, 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]

CBFalconer wrote:

Stephan Hoffmann wrote:

I think some compilers give a warning without the explicit cast.
If so, it's a lousy warning.
Maybe the author wanted to write 'warning-free' code.

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.

If a warning appears it is because it is needed.
Would that that were the case! Some compilers diagnose perfectly good,
idiomatic, ordinary C code. Grrr.

Useless casts serve only to preserve programming errors.

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]

On Sun, 17 Jul 2005 05:53:51 +0000 (UTC), Richard Heathfield
<in*****@address.co.uk.invalid> wrote:

CBFalconer wrote:

Stephan Hoffmann wrote:

I think some compilers give a warning without the explicit cast.
If so, it's a lousy warning.

Yup. There are some lousy compilers out there.

Maybe the author wanted to write 'warning-free' code.
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.

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).
If a warning appears it is because it is needed.

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

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

Useless casts serve only to preserve programming errors.

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

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(my_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]

Chris Croughton <ch***@keristor.net> writes:
[...]

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

Which is why the recommended idiom is

pointer = malloc(sizeof *pointer);

--
Keith Thompson (The_Other_Keith) ks***@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]

Chris Croughton wrote:

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

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_identifier, never sizeof(type).

--
pete

[Tim Woodall]

On Sun, 17 Jul 2005 09:43:49 +0100,
Chris Croughton <ch***@keristor.net> wrote:

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:

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/

[Keith Thompson]

Keith Thompson <ks***@mib.org> writes:

Chris Croughton <ch***@keristor.net> writes:
[...]

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

Which is why the recommended idiom is

pointer = malloc(sizeof *pointer);

Following up to myself ...

On the other hand, the cast could conceivably reveal the error that
"pointer" should be of type my_type, but is actually of type
some_other_type. This assumes that the correct type is more obvious
in the context of the malloc() call than at the point of declaration.
I still think it's more likely to mask an error than to reveal one.

--
Keith Thompson (The_Other_Keith) ks***@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.

[Alexei A. Frounze]

"Tim Woodall" <de*****@woodall.me.uk> wrote in message
....

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

Wasn't that Maxwell? :) And obviosly, someone had to throw a few particles
in to start things rolling.
Alex
P.S. there had been a mathematician before Maxwell to come up with those
equations.

[Tim Rentsch]

Richard Heathfield <in*****@address.co.uk.invalid> writes:

CBFalconer wrote:

If a warning appears it is because it is needed.

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

Well said. *applause*

[Old Wolf]

Chris Croughton wrote:

Richard Heathfield <in*****@address.co.uk.invalid> wrote:

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

Out of interest, which compilers do warn about correct usage of
malloc?

If a warning appears it is because it is needed.

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

The worst I've seen is a warning when you cast something to
the same type it already was. For example:

isprint( (unsigned char)ch );

If you compile with plain char unsigned, it will warn about this
cast.

It gets really annoying in macros, where you often put in casts
because the macro could really be called with any integral type,
and then this compiler would warn when you use the one type that
matches the cast.

It was possible to turn off this warning, but not without also
turning off important warnings. :X
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,
How many platforms have you programmed on where int, size_t,
and void* are not interchangeable, and the compiler does not
have special recognition of standard library functions?
whereas I have come across cases where:

pointer = (my_type*) malloc(sizeof(my_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.

There would not have been any diagnostic in either case, if the
parameter to malloc were wrong, ie.

pointer = (correct_type*) malloc(sizeof(my_type));

So this is a bit of a Pascal's wager.

Note that this problem can be eschewed with:

malloc(sizeof *ptr);

[Keith Thompson]

"Old Wolf" <ol*****@inspire.net.nz> writes:
[...]

The worst I've seen is a warning when you cast something to
the same type it already was. For example:

isprint( (unsigned char)ch );

If you compile with plain char unsigned, it will warn about this
cast.

Even worse, plain char and unsigned char are distinct types, even if
plain char happens to be unsigned. If the compiler complains that the
cast is unnecessary, I can see the point. If it complains that the
argument is of the same type specified in the cast, it's just wrong.

--
Keith Thompson (The_Other_Keith) ks***@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.

[Christian Bau]

In article <kf*************@alumnus.caltech.edu>,
Tim Rentsch <tx*@alumnus.caltech.edu> wrote:

Richard Heathfield <in*****@address.co.uk.invalid> writes:

CBFalconer wrote:

If a warning appears it is because it is needed.

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

Well said. *applause*

Example for _really_ stupid warnings:

unsigned char f (int x) { return (x > 0); }

gives a warning on brain-damaged compilers because (x > 0) has type int,
and conversion from int to unsigned char is not always value conserving,
BUT (x > 0) has a value of 0 or 1 and will be converted without problems.

char f (int x) { return x ? 'y' : 'n'; }

Same problem here; the result of (x ? 'y' : 'n') is of type int, but the
actual result can always be converted to char without problems.

[Chris Croughton]

On 17 Jul 2005 14:02:13 -0700, Old Wolf
<ol*****@inspire.net.nz> wrote:

Chris Croughton wrote:

Richard Heathfield <in*****@address.co.uk.invalid> wrote:

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

Out of interest, which compilers do warn about correct usage of
malloc?

You mean assigning void* to a pointer to non-void? At least one I've
used (could have been the IAR H8 series compiler, but I wouldn't
guarantee it).

If a warning appears it is because it is needed.
Would that that were the case! Some compilers diagnose perfectly
good, idiomatic, ordinary C code. Grrr.
The worst I've seen is a warning when you cast something to
the same type it already was. For example:

isprint( (unsigned char)ch );

If you compile with plain char unsigned, it will warn about this
cast.

Try things like:

unsigned char ch;
int in;
in = getc(stdin);
if (in != EOF)
ch = in;

On some of the ARM compilers it gives a warning:

conversion from 'int ' to 'unsigned char ', possible loss of data
It gets really annoying in macros, where you often put in casts
because the macro could really be called with any integral type,
and then this compiler would warn when you use the one type that
matches the cast.

It was possible to turn off this warning, but not without also
turning off important warnings. :X
Exactly. And the 'silly' warnings can mask the real ones (and even mask
the rrors, I've had occasions where it's taken me a lot of time even to
find the error message knowing that there is one, because it's been lost
in the 'noise' of the spurious warnings).
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,

How many platforms have you programmed on where int, size_t,
and void* are not interchangeable, and the compiler does not
have special recognition of standard library functions?

Lots. Including (but not limited to, these are only the ones which I
remember definitely had different sizes for at least one of those
types):

Z8000
M68000
H8 family
80x86

The only "special recognition" by the compilers has been when the
appropriate header -- and therefore the appropriate prototype -- has
been included.

I haven't programmed for a C compiler where int and void* were
interchangeable without a cast since I left university where we had a
pre-K&R compiler (thinking of it, I don't think it had void at all so
they weren't interchangeable then either).

whereas I have come across cases where:

pointer = (my_type*) malloc(sizeof(my_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.

There would not have been any diagnostic in either case, if the
parameter to malloc were wrong, ie.

pointer = (correct_type*) malloc(sizeof(my_type));

True. Easier is to do something like:

#define NEW(t) ((T*)malloc(sizeof(T)))

and then

int *p = NEW(char);

gives a diagnostic (usually an error, occasionally a warning).
So this is a bit of a Pascal's wager.

Note that this problem can be eschewed with:

malloc(sizeof *ptr);

But that doesn't catch the case where you know what the type should be
and you want to ensure that the pointer is the correct type.

Chris C

[hugo2]

Stephan Hoffmann wrote:

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

Stephan

hugo July 17
Ah! I too had a feeling the casts were not
strickly needed, but were for 'portablitiy'
reasons.
Portability issues are very murky waters
to me, and I don't dive by myself.

[hugo2]

pete wrote:

hugo wrote:

The addresses are all unsigned int.

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.

hugo July 18
As far as I know, addresses are memory locations
and are always integers. Negative or fractional
addresses don't make any sense, do they?
So the addresses are all positive integers,
and that is what is being assigned to pbTo
and pbFrom to initalize them.

That is what I ment.

The 'byte' type is a data type, which I
assumed to have some meaning either in
a header file or a program typedef.
Maguire did not explain it.

hugo.

[Keith Thompson]

"hugo2" <ob****@yahoo.com> writes:

pete wrote:

hugo wrote:

> The addresses are all unsigned int.

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.

hugo July 18
As far as I know, addresses are memory locations
and are always integers. Negative or fractional
addresses don't make any sense, do they?
So the addresses are all positive integers,
and that is what is being assigned to pbTo
and pbFrom to initalize them.

No. Addresses are addresses. The language defines conversions
between addresses (pointers) and integers, but it says very little
about what those conversions do. Basically, if you convert an address
value to an integer big enough to hold it, then convert it back to the
pointer type, you'll get the original value -- but the intermediate
integer value may be completely meaningless.

It happens that, on many actual systems, addresses look a lot like
unsigned integers, but that's an implementation detail.

--
Keith Thompson (The_Other_Keith) ks***@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.

[CBFalconer]

hugo2 wrote:

pete wrote:

hugo wrote:

The addresses are all unsigned int.

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.

As far as I know, addresses are memory locations and are always
integers. Negative or fractional addresses don't make any sense,
do they? So the addresses are all positive integers, and that is
what is being assigned to pbTo and pbFrom to initalize them.

You are surrounded all day by addresses that are not integers. For
example, "1234 W Foo St, Bar, State of Fee, Foe". What makes you
think computers have to linearize their addresses? Some of them
are so linearized, such as which memory chip, L2 Cache or main
memory or virtual memory. But down under that layer the
differences still exist.

--
"If you want to post a followup via groups.google.com, 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