Bug 253839

Summary: sys/buf.h uses bool type that can be undefined since commit 2bfd8992c7c7
Product: Base System Reporter: Guido Falsi <madpilot>
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed Not A Bug    
Severity: Affects Only Me CC: kib
Priority: ---    
Version: CURRENT   
Hardware: Any   
OS: Any   
Bug Depends on:    
Bug Blocks: 253870    
Attachments:
Description Flags
Add include defining bool types. madpilot: maintainer-approval? (kib)

Description Guido Falsi freebsd_committer freebsd_triage 2021-02-25 08:43:27 UTC
Created attachment 222811 [details]
Add include defining bool types.

I was upgrading to recent head and I got this error when compiling port devel/libgtop in poudriere:

In file included from procmap.c:54:
In file included from /usr/include/ufs/ufs/inode.h:50:
/usr/include/sys/buf.h:569:1: error: unknown type name 'bool'
bool    inmem(struct vnode *, daddr_t);
^
procmap.c:101:25: warning: unused variable 'um' [-Wunused-variable]
        struct ufsmount um;
                        ^
procmap.c:405:16: warning: cast from 'gchar *' (aka 'char *') to 'glibtop_map_entry *' (aka 'struct _glibtop_map_entry *') increases required alignment from 1 to 8 [-Wcast-align]
        return (glibtop_map_entry*) g_array_free(maps, FALSE);
               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2 warnings and 1 error generated.
gmake[4]: *** [Makefile:573: procmap.lo] Error 1
gmake[4]: *** Waiting for unfinished jobs....

Looking at sources I noticed commit 2bfd8992c7c7 adding that bool type to sys/buf.h

I'm not sure what the correct cure is. I noticed other system sources including buf.h generally include sys/types.h that defines bool types for c.

I think buf.h should include that one directly since it uses a type defined there.

I'm attaching a patch to this effect.
Comment 1 Konstantin Belousov freebsd_committer freebsd_triage 2021-02-25 13:11:54 UTC
sys/buf.h, or ufs/ufs/inode.h, are internal kernel headers.  Userspace has no
business using them.

If some usermode code tries to (ab)use the kernel headers, it is up to the code
to provide the expected compilation environment.  Also, the FreeBSD traditional
policy for kernel headers is to avoid nested includes, which has a reasoning
behind it.
Comment 2 Guido Falsi freebsd_committer freebsd_triage 2021-02-25 14:12:30 UTC
(In reply to Konstantin Belousov from comment #1)

Thanks for the explanation.

I proposed this patch which looked correct to me, but your explanation makes perfect sense.

I'll close this report and create one against the libgtop port.

Thanks again and sorry for the noise.