boost, dirfd & NetBSD

[Paul Ripke <stix%stix.id.au@localhost>]

Noticed while trying to put together a package with a fairly large
dependency chain:

Our dirfd(3) is a macro:

/usr/include/dirent.h:
...
#define dirfd(dirp)     ((dirp)->dd_fd)
...

Boost assumes it's a function, and uses a c++ namespace qualifier:

/usr/pkg/include/boost/process/detail/posix/handles.hpp:
...
    auto my_fd = ::dirfd(dir.get());
...

which breaks:

ksh$ cat z.cc
#include <boost/process.hpp>

int main(int argc, char **argv) {
        return 0;
}
ksh$ clang++ -c -I/usr/pkg/include z.cc
...
In file included from z.cc:1:
In file included from /usr/pkg/include/boost/process.hpp:23:
In file included from /usr/pkg/include/boost/process/async.hpp:43:
In file included from /usr/pkg/include/boost/process/detail/posix/async_in.hpp:19:
In file included from /usr/pkg/include/boost/process/detail/used_handles.hpp:14:
/usr/pkg/include/boost/process/detail/posix/handles.hpp:34:20: error: expected unqualified-id
    auto my_fd = ::dirfd(dir.get());

I note that POSIX 1003.1-2017 seems to assume dirfd(3) is a function:

https://pubs.opengroup.org/onlinepubs/9699919799/functions/dirfd.html

"The dirfd() function shall return a file descriptor referring to the
same directory as the dirp argument."

but also allows macros, in addition to functions (reading between
the lines a little):

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/dirent.h.html

"The following shall be declared as functions and may also be defined
as macros. Function prototypes shall be provided."

Searching around, {free,open}bsd both have functions, linux appears
to have a function and an optional macro.

Thoughts? A patch to boost is easy enough, but we should probably
just implement a function and be done with it.

(sidenote, how am I the first to notice this?)

-- 
Paul Ripke
"Great minds discuss ideas, average minds discuss events, small minds
 discuss people."
-- Disputed: Often attributed to Eleanor Roosevelt. 1948.