lsearch.c

classic Classic list List threaded Threaded
6 messages Options
enh
Reply | Threaded
Open this post in threaded view
|

lsearch.c

enh
POSIX says lsearch's 'base' is void*, not const void*.

http://pubs.opengroup.org/onlinepubs/9699919799/functions/lsearch.html

openbsd gets this wrong in search.h and lsearch.c. (but lfind is
correct --- that should be const void*.)

 -e

Reply | Threaded
Open this post in threaded view
|

Re: lsearch.c

Matthew Dempsky-3
Hm, is there a practical consequence of this?  Seems like it would
only affect applications trying to store a reference to lsearch in a
function pointer of type "void (*)(const void *, void *, size_t *,
size_t, int (*)(const void *, const void *))"; do those exist?

On Thu, Jul 17, 2014 at 5:38 PM, enh <[hidden email]> wrote:
> POSIX says lsearch's 'base' is void*, not const void*.
>
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/lsearch.html
>
> openbsd gets this wrong in search.h and lsearch.c. (but lfind is
> correct --- that should be const void*.)
>
>  -e
>

enh
Reply | Threaded
Open this post in threaded view
|

Re: lsearch.c

enh
For me (Android) the practical consequence is compiler warnings unless I
change search.h to be wrong.

I'm going through the non-Open BSD stuff I have working out why. In this
case, this seems to be the reason we have the NetBSD search.h
implementation. The majority of our BSD code is OpenBSD so my preference
would be to switch over as much as possible.
On Jul 17, 2014 5:59 PM, "Matthew Dempsky" <[hidden email]> wrote:

> Hm, is there a practical consequence of this?  Seems like it would
> only affect applications trying to store a reference to lsearch in a
> function pointer of type "void (*)(const void *, void *, size_t *,
> size_t, int (*)(const void *, const void *))"; do those exist?
>
> On Thu, Jul 17, 2014 at 5:38 PM, enh <[hidden email]> wrote:
> > POSIX says lsearch's 'base' is void*, not const void*.
> >
> > http://pubs.opengroup.org/onlinepubs/9699919799/functions/lsearch.html
> >
> > openbsd gets this wrong in search.h and lsearch.c. (but lfind is
> > correct --- that should be const void*.)
> >
> >  -e
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: lsearch.c

Matthew Dempsky-3
Hrm.  It seems silly to me to change it to require a non-const pointer
argument, but POSIX, Linux, Solaris, FreeBSD, and NetBSD all use "void
*base" so it doesn't seem like we should have any ports tree issues
from changing it to be compatible either.

On Thu, Jul 17, 2014 at 6:04 PM, enh <[hidden email]> wrote:

> For me (Android) the practical consequence is compiler warnings unless I
> change search.h to be wrong.
>
> I'm going through the non-Open BSD stuff I have working out why. In this
> case, this seems to be the reason we have the NetBSD search.h
> implementation. The majority of our BSD code is OpenBSD so my preference
> would be to switch over as much as possible.
>
> On Jul 17, 2014 5:59 PM, "Matthew Dempsky" <[hidden email]> wrote:
>>
>> Hm, is there a practical consequence of this?  Seems like it would
>> only affect applications trying to store a reference to lsearch in a
>> function pointer of type "void (*)(const void *, void *, size_t *,
>> size_t, int (*)(const void *, const void *))"; do those exist?
>>
>> On Thu, Jul 17, 2014 at 5:38 PM, enh <[hidden email]> wrote:
>> > POSIX says lsearch's 'base' is void*, not const void*.
>> >
>> > http://pubs.opengroup.org/onlinepubs/9699919799/functions/lsearch.html
>> >
>> > openbsd gets this wrong in search.h and lsearch.c. (but lfind is
>> > correct --- that should be const void*.)
>> >
>> >  -e
>> >

Reply | Threaded
Open this post in threaded view
|

Re: lsearch.c

patrick keshishian
On 7/17/14, Matthew Dempsky <[hidden email]> wrote:
> Hrm.  It seems silly to me to change it to require a non-const pointer
> argument,

Silly even though, the description of lsearch says it will modify
("it shall be added at the end of") the table, for which "base
argument points to the first element"?

analogy: dst in strlcat() being declared const char *?

--patrick


> but POSIX, Linux, Solaris, FreeBSD, and NetBSD all use "void
> *base" so it doesn't seem like we should have any ports tree issues
> from changing it to be compatible either.
>
> On Thu, Jul 17, 2014 at 6:04 PM, enh <[hidden email]> wrote:
>> For me (Android) the practical consequence is compiler warnings unless I
>> change search.h to be wrong.
>>
>> I'm going through the non-Open BSD stuff I have working out why. In this
>> case, this seems to be the reason we have the NetBSD search.h
>> implementation. The majority of our BSD code is OpenBSD so my preference
>> would be to switch over as much as possible.
>>
>> On Jul 17, 2014 5:59 PM, "Matthew Dempsky" <[hidden email]> wrote:
>>>
>>> Hm, is there a practical consequence of this?  Seems like it would
>>> only affect applications trying to store a reference to lsearch in a
>>> function pointer of type "void (*)(const void *, void *, size_t *,
>>> size_t, int (*)(const void *, const void *))"; do those exist?
>>>
>>> On Thu, Jul 17, 2014 at 5:38 PM, enh <[hidden email]> wrote:
>>> > POSIX says lsearch's 'base' is void*, not const void*.
>>> >
>>> > http://pubs.opengroup.org/onlinepubs/9699919799/functions/lsearch.html
>>> >
>>> > openbsd gets this wrong in search.h and lsearch.c. (but lfind is
>>> > correct --- that should be const void*.)
>>> >
>>> >  -e
>>> >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: lsearch.c

Matthew Dempsky-3
On Thu, Jul 17, 2014 at 8:05 PM, patrick keshishian <[hidden email]> wrote:
> Silly even though, the description of lsearch says it will modify
> ("it shall be added at the end of") the table, for which "base
> argument points to the first element"?

Ah, I didn't pay close attention to the definition and assumed it was
simply a search function like memchr() or strstr().  If it might
modify memory, then yes, making it non-const absolutely makes sense.