[Bug 297082] mknod(2) should support creating FIFOs for POSIX compliance
[email protected] Mon, 27 Jul 2026 12:05:23 +0000
| Newsgroups | gmane.os.freebsd.devel.standards |
|---|---|
| Message-ID | <[email protected]/bugzilla/> |
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D297082
Bug ID: 297082
Summary: mknod(2) should support creating FIFOs for POSIX
compliance
Product: Base System
Version: 16.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: standards
Assignee: [email protected]
Reporter: [email protected]
The POSIX spec for mknod[*1] says: =E2=80=9CThe only portable use of mknod(=
) is to
create a FIFO-special file. If mode is not S_IFIFO or dev is not 0, the
behavior of mknod() is unspecified.=E2=80=9D
Whereas the mknod(2) manual page says, for error code `EINVAL`: =E2=80=9CCr=
eating
anything else than a block or character special file (or a whiteout) is not
supported.=E2=80=9D
This leaves no overlap between the spec and FreeBSD. I know mknod is
deprecated, but this is still a portability issue. It just bit me
yesterday[*2], as I'm maintaining ksh93's built-in versions of cp(1) and mv=
(1),
which must deal with special files too.
It seems to me like the fix should be trivial: mknod(2) could simply hand o=
ff
to mkfifo(2) if mode =3D=3D S_IFIFO. I can't imagine a conceivable downside.
[*1] https://pubs.opengroup.org/onlinepubs/9799919799/functions/mknod.html
[*2] https://github.com/ksh93/ksh/commit/2b777083445a21e33ff2482b09bc4b4bf
--=20
You are receiving this mail because:
You are the assignee for the bug.=