Date: Sat, 9 Mar 2024 21:23:05 -0800 From: Mark Millard <marklmi@yahoo.com> To: freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Header inclusion question(s), for example use of cpusetid_t vs/ explicit inclusion of sys/types.h Message-ID: <6D583EFB-BD79-49F9-BCA9-AB22DA77DFB8@yahoo.com> References: <6D583EFB-BD79-49F9-BCA9-AB22DA77DFB8.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
FYI: /usr/include/sys/types.h:typedef __cpusetid_t cpusetid_t; I've been experimenting with clang-tidy (really clang-tidy18 in a llvm17 libc++ context). Its misc-* checks include reporting when the likes of: / . . . : warning: no header providing "cpusetid_t" is directly included = [misc-include-cleaner] In other words, it is suggesting an explicit include: #include <sys/types.h> // for cpusetid_t no matter if it is indirectly included or not. I'll note that clang_tidy also reports the likes of: / . . . : : warning: included header param.h is not used directly = [misc-include-cleaner] if nothing directly provided in sys/param.h is referenced, in other words, if sys/param.h is at most indirectly causing other files to provide some of what happens to be used in the translation unit. My overall question is: is it generally reasonable to follow the suggestions that would eliminate these shorts of clang-tidy reports? Basically: include just the files that directly provides what happens to be directly used in a transition unit. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6D583EFB-BD79-49F9-BCA9-AB22DA77DFB8>