On systems using dsymutil the check for the "-g" flag was failing not
because the compiler didn't provide it but because of `/dev/null`
being used as output file.
---
This happened on MacOS where I discovered the issue executing `cc -g -v
-o /dev/null check.c`. Here's the relevant part of the output (I'm adding 
it here just in case someone searches for this error):
...
"/Library/Developer/CommandLineTools/usr/bin/dsymutil" -o /dev/null.dSYM /dev/null
error: cannot parse the debug map for '/dev/null': The file was not recognized as a valid object file
clang: error: dsymutil command failed with exit code 1 (use -v to see invocation)

 config.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
[message trimmed]

Those changes fix the following compilation errors on OpenBSD:

src/tofu.c:128:28: error: format specifies type 'long' but the argument has type
      'time_t' (aka 'long long') [-Werror,-Wformat]
                        "SHA-512", fingerprint, expires);

src/gmnlm.c:341:31: error: missing sentinel in function call
      [-Werror,-Wsentinel]
                execlp("sh", "sh", "-c", cmd);
                                            ^
                                            , NULL
---
Sorry I totally missed the cast to intmax_t of `expires` in the previous
mail!
[message trimmed]

Those changes fix the following compilation errors on OpenBSD:

src/tofu.c:128:28: error: format specifies type 'long' but the argument has type
      'time_t' (aka 'long long') [-Werror,-Wformat]
                        "SHA-512", fingerprint, expires);

src/gmnlm.c:341:31: error: missing sentinel in function call
      [-Werror,-Wsentinel]
                execlp("sh", "sh", "-c", cmd);
                                            ^
                                            , NULL
---
I followed Eyal Sawady's suggestion and replaced `lld` of the previous
patch with `jd` in the format string.
[message trimmed]

Nice, thanks!

Sorry I just noticed this patch would break compilation on other
systems (the majority) where `time_t` is a long and not a long long.

Do you think it would be worth introducing conditional compilation to
solve this issue? (unfortunately I can't think of other simpler
solutions)

Those changes fix the following compilation errors on OpenBSD:

src/tofu.c:128:28: error: format specifies type 'long' but the argument has type
      'time_t' (aka 'long long') [-Werror,-Wformat]
                        "SHA-512", fingerprint, expires);

src/gmnlm.c:341:31: error: missing sentinel in function call
      [-Werror,-Wsentinel]
                execlp("sh", "sh", "-c", cmd);
                                            ^
                                            , NULL
---
 src/gmnlm.c | 2 +-
 src/tofu.c  | 2 +-
[message trimmed]

On some systems dirname uses a static string for its return value, so
we were calling mkdirs recursively on a string that was continuosly changing.

A check was also added after the `snprintf` to make sure there's no
information loss since there is no limit to the length of the string
returned by `get_data_pathfmt`.

Closes #48.
---
Sorry I just realized there was a bug in the previous patch.
In `tofu.c` I moved the initialization of the `n` variable but forget
to set it's value again at 0 before it's used in the `getline` call.

 src/gmnlm.c | 18 ++++++++++++++----
[message trimmed]

On some systems dirname uses a static string for its return value, so
we were calling mkdirs recursively on a string that was continuosly changing.

A check was also added after the `snprintf` to make sure there's no
information loss since there is no limit to the length of the string
returned by `get_data_pathfmt`.

Closes #48.
---
 src/gmnlm.c | 18 ++++++++++++++----
 src/tofu.c  | 10 +++++++---
 2 files changed, 21 insertions(+), 7 deletions(-)

diff --git a/src/gmnlm.c b/src/gmnlm.c
[message trimmed]

On Tue, Nov 10, 2020 at 01:06:24PM -0400, Drew DeVault wrote:
> Yeah, since these are truncated when the length exceeds the buffer size,
> we need an assertion to make sure that it did not, in fact, exceed the
> buffer size, before we go using that buffer under the assumption that it
> is sound.

Hmm okay for the path variable but is it really necessary also for
dname? `dirname(path)` should always return a string that is less than
or equal in lenght to `path` and `dname` is allocated a buffer of the
same size (PATH_MAX +1).

If we check that everything is ok with the path, eg:
```
int n;

On Sun, Nov 08, 2020 at 10:36:40AM -0400, Drew DeVault wrote:
> Can you use strncpy here and use a defensive approach against buffer
> overflows? It's fine to just assert that the expectations are met, but
> we need to check.

Sure! I'll use `strncpy(dname, dirname(path), sizeof(dname))` instead of 
`strcpy(dname, dirname(path))`.

Could you please explain a bit more what do you mean for taking a 
defensive approach against buffer overflows? Is that enough or should I
add an assert of some kind on what is going on with those strings
operations? 

By the way I noticed that we should check that snprintf is successfully