is const necessary in eg int compar(const void *, const void *)

[lovecreatesbeauty]

Is the keyword const necessary in the comparison function in qsort and
bsearch?

int (*compar)(const void *, const void *)

If the pointer cannot be dereferenced why worry if the pointed object
will be modified?

[Ian Collins]

lo************* **@gmail.c0m wrote:

Is the keyword const necessary in the comparison function in qsort and
bsearch?

int (*compar)(const void *, const void *)

If the pointer cannot be dereferenced why worry if the pointed object
will be modified?

Why can't the pointer be dereferenced?

--
Ian Collins

[Peter Nilsson]

"lovecreatesbea ...@gmail.c0m" <lovecreatesbea [e-mail] ote:

Is the keyword const necessary in the comparison function
in qsort and bsearch?

Not strictly necessary, but prudent.

int (*compar)(const void *, const void *)

If the pointer cannot be dereferenced why worry if the
pointed object will be modified?

When the pointer(s) are converted to the appropriate object
type, they certainly can be dereferenced, and usually are.

--
Peter

[lovecreatesbeauty]

On Oct 15, 10:55 am, Peter Nilsson <[e-mail] .auwrote:

"lovecreatesbea ...@gmail.c0m" <lovecreatesbea [e-mail] ote:

Is the keyword const necessary in the comparison function
in qsort and bsearch?

Not strictly necessary, but prudent.

int (*compar)(const void *, const void *)

If the pointer cannot be dereferenced why worry if the
pointed object will be modified?

When the pointer(s) are converted to the appropriate object
type, they certainly can be dereferenced, and usually are.

Thank you.

I ignored this, the const qualifier on the original pointers will
still require the same qulifier to be applied on those appropriate
object.

[Richard Heathfield]

lo************* **@gmail.c0m said:

Is the keyword const necessary in the comparison function in qsort and
bsearch?

int (*compar)(const void *, const void *)

Yes.

If the pointer cannot be dereferenced why worry if the pointed object
will be modified?

The pointer *can* be dereferenced after conversion to the appropriate type.
For example, look at all the dereferencing going on here:

#include <time.h>

int cmp_tm(const void *vleft, const void *vright)
{
const struct tm *left = vleft;
const struct tm *right = vright;
int diff =
(left->tm_year right->tm_year) - (left->tm_year < right->tm_year);
if(0 == diff)
{
diff =
(left->tm_mon right->tm_mon) - (left->tm_mon < right->tm_mon);
}
if(0 == diff)
{
diff =
(left->tm_mday right->tm_mday) - (left->tm_mday < right->tm_mday);
}
/* hour, min, sec similarly */

return diff;
}
--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[lovecreatesbeauty]

On Oct 15, 11:16*am, Richard Heathfield <[e-mail].i nvalidwrote:

lovecreatesbea. ..@gmail.c0m said:

If the pointer cannot be dereferenced why worry if the pointed object
will be modified?

The pointer *can* be dereferenced after conversion to the appropriate type.
For example, look at all the dereferencing going on here:

Yes, thanks. I got it.

* if(0 == diff)
* {
* * diff =
* * (left->tm_mon right->tm_mon) - (left->tm_mon < right->tm_mon);
* }
* if(0 == diff)
* {
* * diff =
* * (left->tm_mday right->tm_mday) - (left->tm_mday < right->tm_mday);
* }

why don't you put your code together and create another same selection
block :)

[Richard Heathfield]

lo************* **@gmail.c0m said:

On Oct 15, 11:16 am, Richard Heathfield <[e-mail].i nvalidwrote:

>lovecreatesbea ...@gmail.c0m said:

If the pointer cannot be dereferenced why worry if the pointed object
will be modified?

The pointer *can* be dereferenced after conversion to the appropriate
type. For example, look at all the dereferencing going on here:

Yes, thanks. I got it.

>if(0 == diff)
{
diff =
(left->tm_mon right->tm_mon) - (left->tm_mon < right->tm_mon);
}
if(0 == diff)
{
diff =
(left->tm_mday right->tm_mday) - (left->tm_mday < right->tm_mday);
}

why don't you put your code together and create another same selection
block :)

I haven't the faintest idea what you're talking about.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Nate Eldredge]

"lo************ ***@gmail.c0m" <lo************ ***@gmail.comwr ites:

On Oct 15, 10:55 am, Peter Nilsson <[e-mail] .auwrote:

>"lovecreatesbe a...@gmail.c0m" <lovecreatesbea [e-mail] ote:

Is the keyword const necessary in the comparison function
in qsort and bsearch?

Not strictly necessary, but prudent.

int (*compar)(const void *, const void *)

If the pointer cannot be dereferenced why worry if the
pointed object will be modified?

When the pointer(s) are converted to the appropriate object
type, they certainly can be dereferenced, and usually are.

Thank you.

I ignored this, the const qualifier on the original pointers will
still require the same qulifier to be applied on those appropriate
object.

Hmm, but wait a minute. I think your original point was valid.

For a function like

void foo(const int *p) { /* ... */ }

the compiler will complain if you attempt to assign to, or otherwise
modify, *p. So the compiler helps you make good on the promise you're
making to the caller, that *p will not be modified; this is the whole
point of const. You could circumvent this by assigning to *(int *)p,
but at least the fact that you had to introduce a cast serves as warning
that you might be doing something wrong.

But for a function like

void bar(const void *p) { /* ... */ }

where p is known to point to an int, you *have* to cast p before you can
do much with it. And if you're going to cast it, you could just as
easily cast it to `int *' as to `const int *', and the compiler will (in
my tests) remain silent either way. So the help you get from using
const is much less.

Now if we also have

void qux(void *);

and `bar' attempts to call `qux(p)', the compiler does whine. (This in
fact is exactly the whine that occurs if you pass a function taking
`void *' arguments to `qsort'.) But certainly a lot of the protection
has been lost. One could argue that this makes the use of
`const void *' sort of pointless, but if nothing else it provides some
documentation, I suppose.

[Richard Heathfield]

Nate Eldredge said:

<snip>

But for a function like

void bar(const void *p) { /* ... */ }

where p is known to point to an int, you *have* to cast p before you can
do much with it.

Not so:

#include <stdio.h>

void bar(const void *p)
{
const int *pi = p;
printf("%d\n", *pi);
} /* look, ma, no casts */

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[James Kuyper]

lo************* **@gmail.c0m wrote:

On Oct 15, 11:16 am, Richard Heathfield <[e-mail].i nvalidwrote:

>lovecreatesbea ...@gmail.c0m said:

>>If the pointer cannot be dereferenced why worry if the pointed object
will be modified?

The pointer *can* be dereferenced after conversion to the appropriate type.
For example, look at all the dereferencing going on here:

Yes, thanks. I got it.

> if(0 == diff)
{
diff =
(left->tm_mon right->tm_mon) - (left->tm_mon < right->tm_mon);
}
if(0 == diff)
{
diff =
(left->tm_mday right->tm_mday) - (left->tm_mday < right->tm_mday);
}

why don't you put your code together and create another same selection
block :)

If the value of diff was 0 at the first if(), then diff gets
recalculated, in which case it might be non-0 for the second if(), so
you can't combine the two blocks into a single if() block.