Fix OpenBSD support and clean code

[yukiteruamano]

Hi!

Here I'm making a few small changes to help maintain support for OpenBSD.

First, OpenBSD doesn't support wordexp.h, so the new version of string_to_path in src/utils.c prevents us from compiling. A condition in processing doesn't help to avoid this situation.

As for the rest, I've made a minor change in config.mk, to give better default support to GNU Make (detecting the OS and adjusting the corresponding flags) and some changes to prevent clang/gcc from crying for -Wformat errors.

I'll be waiting for any notes or suggestions.

[bynect]

hello, thanks for the pr. maybe we can come up with a fix for wordexp or a polyfill

anyway it seems gcc doesn't like lld

 error: format '%lld' expects argument of type 'long long int', but argument 4 has type 'gint64' {aka 'long int'} [-Werror=format=]

[yukiteruamano]

Hi @bynect

Well, it seems to me that glib is our special case at this point.

On GNU/Linux, gint64 is seen as long, but on OpenBSD it is seen as long long (I don't know how it will look on FreeBSD, but it is most likely identical to GNU/Linux).

This would explain why the changes are not compiled on GNU/Linux but are compiled on OpenBSD using clang-16 and GCC 8.4.0. Looking at the Glib doc, I see that they are aware that gint64 can change depending on the platform.

https://docs.gtk.org/glib/types.html#gint64

[bynect]

quite the conundrum. maybe we should use the printing macro like <inttypes.h>.

anyway I think we can add a workflow to test openbsd and other os. i'll look into that

[bynect]

@yukiteruamano I made #1424 to address the problem of int you had. However I don't know how to fix the missing wordexp. I read some openbsd forums and indeed using wordexp at all doesn't seem so good, but I don't know an alternative right now