void pointer arithmetic

[Alex Fraser]

From searching Google Groups, I understand that void pointer arithmetic is a
constraint violation, which is understandable. However, generic functions
like qsort() and bsearch() must in essence do exactly this, and similarly
generic functions seem to have useful applications.

In a few posts I read, it was suggested to avoid void pointer arithmetic by
casting to a char pointer, and performing arithmetic on that (in multiples
of sizeof(original _type)). Thus the pointer is cast through the sequence
original_type* -> void* -> char* -> void* -> original_type*.

I am quite sure this would work on many implementations (where the casts are
no-ops), but the threads I saw containing the above suggestion did not make
clear whether or not it was undefined (or implementation defined)
behaviour - is it? If so, is there any way to achieve the desired effect
while strictly conforming to the standards?

TIA,
Alex

[Richard Heathfield]

Dan Pop wrote:

In <HB************ **@bombur.uio.n o> Hallvard B Furuseth
<h.b.furuseth(n ospam)@usit.uio (nospam).no> writes:

<snip>

If you want to _implement_ qsort, you need to cast to char* and do
pointer arithmetic on the result. If you want to _use_ it, you almost
certainly need not.

Are you reading impaired, or what? He explicitly told you that he was
talking about the *implementation * of qsort and bsearch and, as you
agree, the casts are unavoidable. So, where is he wrong?

A small nit: the /conversions/ are unavoidable. They can, however, be
implicit conversions. They do not need to be casts. All you need is a spare
char * to hold the relevant pointer value. (Or possibly more than one. I
haven't checked.)

--
Richard Heathfield : bi****@eton.pow ernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Dan Pop]

In <bp**********@h ercules.btinter net.com> Richard Heathfield <do******@addre ss.co.uk.invali d> writes:

Dan Pop wrote:

In <HB************ **@bombur.uio.n o> Hallvard B Furuseth
<h.b.furuseth(n ospam)@usit.uio (nospam).no> writes:

<snip>

If you want to _implement_ qsort, you need to cast to char* and do
pointer arithmetic on the result. If you want to _use_ it, you almost
certainly need not.

Are you reading impaired, or what? He explicitly told you that he was
talking about the *implementation * of qsort and bsearch and, as you
agree, the casts are unavoidable. So, where is he wrong?

A small nit: the /conversions/ are unavoidable. They can, however, be
implicit conversions. They do not need to be casts. All you need is a spare
char * to hold the relevant pointer value. (Or possibly more than one. I
haven't checked.)

But that's the point: the casts (which are effectively no-ops in terms of
generated code) avoid the need of temporary pointers that serve no other
purpose than avoiding the casts.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Richard Heathfield]

Dan Pop wrote:

In <bp**********@h ercules.btinter net.com> Richard Heathfield
<do******@addre ss.co.uk.invali d> writes:

A small nit: the /conversions/ are unavoidable. They can, however, be
implicit conversions. They do not need to be casts. All you need is a
spare char * to hold the relevant pointer value. (Or possibly more than
one. I haven't checked.)

But that's the point: the casts (which are effectively no-ops in terms of
generated code) avoid the need of temporary pointers that serve no other
purpose than avoiding the casts.

You missed the *primary* purpose of the temporary pointers, which is that
they make the code easier to read.

--
Richard Heathfield : bi****@eton.pow ernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[karl malbrain]

Richard Heathfield <do******@addre ss.co.uk.invali d> wrote in message news:<bp******* ***@titan.btint ernet.com>...

Dan Pop wrote:

In <bp**********@h ercules.btinter net.com> Richard Heathfield
<do******@addre ss.co.uk.invali d> writes:

A small nit: the /conversions/ are unavoidable. They can, however, be
implicit conversions. They do not need to be casts. All you need is a
spare char * to hold the relevant pointer value. (Or possibly more than
one. I haven't checked.)

But that's the point: the casts (which are effectively no-ops in terms of
generated code) avoid the need of temporary pointers that serve no other
purpose than avoiding the casts.

You missed the *primary* purpose of the temporary pointers, which is that
they make the code easier to read.

It also makes for a disciplined evaluation of NULL pointers, as in:

MyStruct *my;
void *voidmyptr;

if( my = voidmyptr )
continue ok;
else
return errpunt ("My struct doesn't exist"

SO, I'm with you on this one, 100%. karl m

[Richard Heathfield]

karl malbrain wrote:

Richard Heathfield <do******@addre ss.co.uk.invali d> wrote in message
news:<bp******* ***@titan.btint ernet.com>...

Dan Pop wrote:

> But that's the point: the casts (which are effectively no-ops in terms
> of generated code) avoid the need of temporary pointers that serve no
> other purpose than avoiding the casts.

You missed the *primary* purpose of the temporary pointers, which is that
they make the code easier to read.

It also makes for a disciplined evaluation of NULL pointers, as in:

MyStruct *my;
void *voidmyptr;

if( my = voidmyptr )
continue ok;
else
return errpunt ("My struct doesn't exist"

SO, I'm with you on this one, 100%. karl m

Nevertheless, I stand by what I said.
--
Richard Heathfield : bi****@eton.pow ernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Dan Pop]

In <bp**********@t itan.btinternet .com> Richard Heathfield <do******@addre ss.co.uk.invali d> writes:

Dan Pop wrote:

In <bp**********@h ercules.btinter net.com> Richard Heathfield
<do******@addre ss.co.uk.invali d> writes:

A small nit: the /conversions/ are unavoidable. They can, however, be
implicit conversions. They do not need to be casts. All you need is a
spare char * to hold the relevant pointer value. (Or possibly more than
one. I haven't checked.)

But that's the point: the casts (which are effectively no-ops in terms of
generated code) avoid the need of temporary pointers that serve no other
purpose than avoiding the casts.

You missed the *primary* purpose of the temporary pointers, which is that
they make the code easier to read.

That's not automatically true in my experience. It heavily depends on the
context.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Richard Bos]

Richard Heathfield <do******@addre ss.co.uk.invali d> wrote:

Dan Pop wrote:

But that's the point: the casts (which are effectively no-ops in terms of
generated code) avoid the need of temporary pointers that serve no other
purpose than avoiding the casts.

You missed the *primary* purpose of the temporary pointers, which is that
they make the code easier to read.

Says you. In some often-occurring cases (e.g., qsort()ing strings using
a wrapper for strcpy()), the cast version is, IMO, easier to read than
the extra-object version.

Richard

[Al Bowers]

Richard Bos wrote:

Richard Heathfield <do******@addre ss.co.uk.invali d> wrote:

Dan Pop wrote:

But that's the point: the casts (which are effectively no-ops in terms of
generated code) avoid the need of temporary pointers that serve no other
purpose than avoiding the casts.

You missed the *primary* purpose of the temporary pointers, which is that
they make the code easier to read.

Says you. In some often-occurring cases (e.g., qsort()ing strings using
a wrapper for strcpy()), the cast version is, IMO, easier to read than
the extra-object version.

What is this often-occuring case (qsort()ing strings using a
wrapper for strcpy()?

--
Al Bowers
Tampa, Fl USA
mailto: xa******@myrapi dsys.com (remove the x to send email)
http://www.geocities.com/abowers822/

[Dan Pop]

In <bp************ *@ID-169908.news.uni-berlin.de> Al Bowers <xa******@rapid sys.com> writes:

Richard Bos wrote:

Richard Heathfield <do******@addre ss.co.uk.invali d> wrote:

Dan Pop wrote:

But that's the point: the casts (which are effectively no-ops in terms of
generated code) avoid the need of temporary pointers that serve no other
purpose than avoiding the casts.

You missed the *primary* purpose of the temporary pointers, which is that
they make the code easier to read.

Says you. In some often-occurring cases (e.g., qsort()ing strings using
a wrapper for strcpy()), the cast version is, IMO, easier to read than
the extra-object version.

What is this often-occuring case (qsort()ing strings using a
wrapper for strcpy()?

Obvious typo: he meant strcmp(). Consider the case when the comparison
has to omit a fixed length header, that might contain binary data:

int compare(const void *s1, const void *s2)
{
return strcmp((char *)s1 + OFFSET, (char *)s2 + OFFSET);
}

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Jeremy Yallop]

Dan Pop wrote:

In <bp************ *@ID-169908.news.uni-berlin.de> Al Bowers <xa******@rapid sys.com> writes:

Richard Bos wrote:

Richard Heathfield <do******@addre ss.co.uk.invali d> wrote:

Dan Pop wrote:

>But that's the point: the casts (which are effectively no-ops in terms of
>generate d code) avoid the need of temporary pointers that serve no other
>purpose than avoiding the casts.

You missed the *primary* purpose of the temporary pointers, which is that
they make the code easier to read.
Says you. In some often-occurring cases (e.g., qsort()ing strings using
a wrapper for strcpy()), the cast version is, IMO, easier to read than
the extra-object version.

What is this often-occuring case (qsort()ing strings using a
wrapper for strcpy()?

Obvious typo: he meant strcmp(). Consider the case when the comparison
has to omit a fixed length header, that might contain binary data:

int compare(const void *s1, const void *s2)
{
return strcmp((char *)s1 + OFFSET, (char *)s2 + OFFSET);
}

I think this needs to be something like:

int compare(const void *s1, const void *s2)
{
return strcmp(*(char **)s1 + OFFSET, *(char **)s2 + OFFSET);
}

Jeremy.