I'm personally not a fan of the *_s() functions. That said, we've already added some others to the base system, so there's probably no turning back.

What about making the macros identical? That way there is no need for a guard. s/field/member/

In D12380#256994, @emaste wrote:

Interesting. We do have a number of examples of ##__VA_ARGS__ in other headers, although it may well be that in practice they'll never be included in C++ source.

Wait. So the intent of this change is that we should disallow cap_rights_init(), etc. calls with empty arguments, right? If so, that's already prohibited right now:

I'm personally not a big fan of going into this direction. The problem with these constants is that they are defined in the first place. A lot of people don't realise that POSIX allows us to omit PATH_MAX and NAME_MAX entirely. By omitting them, you specify that these limits are not known at compile-time for this implementation. This is in our case arguably even more correct, as in our environment, the actual value depends on the mount point. The true limit may then be extracted using pathconf().

Also apply cleanups to devel/cloudabi/Makefile.

In D12103#253343, @riggs wrote:

Minor thing: If you don't expect the plist to become larger soon, I'd probably follow portlint's recommendation to use PLIST_FILES inside the Makefile rather than having pkg-plist.

In D12068#252037, @koobs wrote:

Looks OK, pending confirmation that port passes QA (poudriere w/ Python 3.x)

s/LOCALBASE/PREFIX/

Process mat@'s feedback.

Friendly ping. :-)

Thanks for the feedback. Really appreciated!

Process feedback provided by mat@.

Wow! Thanks for reviewing this change so quickly!

Add a proper pkg-descr.

Revert premature change to devel/Makefile.

The problem with this change is that I'm not 100% sure this won't cause an infinite amount of recursion in the TTY layer. Basically, this is what's happening:

In D11780#244447, @truckman wrote:

Changing this is an ABI change that could affect some existing binaries

Also to clarify what CloudABI does:

Don, thanks for pointing me to this discussion!

In D11733#243241, @mat wrote:

You should probably add this before the RUN_DEPENDS line:

IGNORE_FreeBSD_10= only for 11+