Bug 253839 - sys/buf.h uses bool type that can be undefined since commit 2bfd8992c7c7
Summary: sys/buf.h uses bool type that can be undefined since commit 2bfd8992c7c7
Status: Closed Not A Bug
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
Depends on:
Blocks: 253870
  Show dependency treegraph
Reported: 2021-02-25 08:43 UTC by Guido Falsi
Modified: 2021-02-26 11:03 UTC (History)
1 user (show)

See Also:

Add include defining bool types. (538 bytes, patch)
2021-02-25 08:43 UTC, Guido Falsi
madpilot: maintainer-approval? (kib)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Guido Falsi freebsd_committer 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 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 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.