Consider using Boost

[dewyatt]

Description

Some of our code is reinventing the wheel because 1) we use c++11 and 2) we don't really have many dependencies.

Certain things, like dealing with filesystem paths, can be tricky from both a safety and portability standpoint. Looking through the code base with something like grep -r "'/'" src/ | grep '==' makes me think there's some potential portability issues since Windows generally supports both / and \ as path separators.

Somewhat related, many uses of strncpy I see in the code base likely make incorrect assumptions and are not safe (something like BSD's strlcpy would be better).

I haven't put a ton of thought into this, but I think it may be worth considering Boost at this point. Boost.Filesystem, Boost.Format, Boost.Optional, all look like they could be helpful for us. We might even want to consider Boost.Outcome.

Of course we would want to be sure to properly handle exceptions if we did take this route.

[ronaldtse]

@dewyatt agree with using Boost since we don't want to reinvent general purpose code.

[ronaldtse]

Thoughts @ni4?

[ni4]

@ronaldtse @dewyatt agree with using Boost but I have doubts about another dependency - will not this make building/testing process more complicated?

And, on OpenPGP layer we do not use much of non-portable code/may replace srncpy with something better. So probably we could attach Boost on CLI layer only, keeping library's dependency list as short as possible?

[dewyatt]

@ronaldtse @dewyatt agree with using Boost but I have doubts about another dependency - will not this make building/testing process more complicated?

And, on OpenPGP layer we do not use much of non-portable code/may replace srncpy with something better. So probably we could attach Boost on CLI layer only, keeping library's dependency list as short as possible?

It depends on what boost libs we use really, some are header-only and we may be able to pull them in automatically in CMake etc.

[ni4]

@dewyatt Got it. Sure then, let's use Boost.