Date: Mon, 17 Aug 2020 21:42:49 -0700 From: Mark Millard <marklmi@yahoo.com> To: FreeBSD Current <freebsd-current@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org> Subject: CPU_FFS, its ffsl use, and the need for including <strings.h> if using "ISO" compiler modes Message-ID: <5C4EB8F3-F184-4FC0-82CD-4A0B8CFCAF9D@yahoo.com> References: <5C4EB8F3-F184-4FC0-82CD-4A0B8CFCAF9D.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5C4EB8F3-F184-4FC0-82CD-4A0B8CFCAF9D>