On 7/17/14, Matthew Dempsky <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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
>>> >
>
>
