CPU_FFS, its ffsl use, and the need for including <strings.h> if using "ISO" compiler modes

In a aarch64 head -r363590 context with g++9 from ports
in use (so ffsl is only compiler-defined outside strict
ISO modes) . . .

I got a compile failure for using CPU_FFS because ffsl
"was not declared". My code was being compiled via
-std=c++17 . (Other than enabling one feature, it is
not system specific code overall.)

Well, it turns out that /usr/include/sys/bitset.h is
indirectly used by /usr/include/sys/cpuset.h and
bitset.h has use of ffsl in BIT_FFS but bitset.h does
nothing to cause use of a:

#include <strings.h>

to pick up the FreeBSD's libc declaration of the ffsl
routine. (There are other "bit string" routines with
similar issues.)

Nor does "man 2 cpuset" or /usr/include/sys/cpuset.h
or /usr/include/sys/bitset.h explicitly suggest the
potential need for including <strings.h> to declare
things used by the header files that are mentioned
in those places.

I'll note that g++10 did not object before this
change. But I had reason to also build using g++9 .

[Compiling the <strings.h>-updated code with g++10
did not complain. Nor did linking the results
complain.]

Note: The c++17 code involved is not part of a
FreeBSD port.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)