On Mon, 2020-02-03 at 11:55 -0600, Denis Kenzior wrote:
Hi Robert,
On 2/1/20 1:53 AM, Robert Joslyn wrote:
> The rawmemchr function is a GNU extension, and not available in other
> libc implementations, such as musl.
> ---
> src/wiphy.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/wiphy.c b/src/wiphy.c
> index 1da479db..141b3cb9 100644
> --- a/src/wiphy.c
> +++ b/src/wiphy.c
> @@ -500,7 +500,7 @@ const uint8_t *wiphy_get_supported_rates(struct
> wiphy *wiphy, unsigned int band,
>
> if (out_num)
> *out_num =
> - (uint8_t *) rawmemchr(wiphy-
> >supported_rates[band], 0) -
> + (uint8_t *) memchr(wiphy->supported_rates[band],
> 0, (size_t)-1) -
> wiphy->supported_rates[band];
>
> return wiphy->supported_rates[band];
>
Unfortunately this causes gcc to complain:
src/wiphy.c: In function ‘wiphy_get_supported_rates’:
src/wiphy.c:503:16: error: ‘memchr’ specified size 18446744073709551615
exceeds maximum object size 9223372036854775807 [-Werror=stringop-
overflow=]
503 | (uint8_t *) memchr(wiphy->supported_rates[band], 0,
(size_t)-1) -
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
can you try the attached patch instead?
Regards,
-Denis
Hi Denis,
Sorry about that. I'm doing my builds with Yocto/OpenEmbedded (master
branch) and was able to build with both glibc and musl with my original
patch, but compile flags or gcc version are probably different.
Your patch works fine for me and looks like a better approach.
This got me curious, so I looked at what glibc does:
http://sourceware.org/git/?p=glibc.git;a=blob;f=string/rawmemchr.c;h=b62d...
I expect the use of strlen when looking for null is slightly faster, but
probably doesn't really matter here.
Thanks for taking a look and working on a fix!
Robert