tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

boost, dirfd & NetBSD

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

Our dirfd(3) is a macro:

#define dirfd(dirp)     ((dirp)->dd_fd)

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

    auto my_fd = ::dirfd(dir.get());

which breaks:

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

int main(int argc, char **argv) {
        return 0;
ksh$ clang++ -c -I/usr/pkg/include
In file included from
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:

"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):

"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.

Home | Main Index | Thread Index | Old Index