NuxiNL/cloudlibc

How to assert()?

mcandre opened this issue · 4 comments

Could cloudlibc offer a dassert() macro that accepts a file descriptor for emitting assertion errors? Is this even possible, given that assert() tends to hook deep into C++ throw?

Alternatively, NuxiNL/cloudabi-utils#11 would be fantastic!

I suspect this may be possible with dup2(), though I'm not sure how portable that function is.

Ideally, cloudlibc would have no observable global mutable state, and thus no global stdio streams (stdin, stdout, stderr). As you pointed out, this would be annoying for assert(), which doesn't take an explicit logging sink.

Though I think people should write their software in a dependency injected way, I think we can also agree that requiring software to have logging sinks injected (both for events and failure diagnostics) would be far too pedantic. This is why cloudlibc does provide a stderr. The following libc interfaces write to stderr:

  • Assertions: assert(),
  • Error message printing: fmtmsg(), perror() and psignal(),
  • Logging: syslog().

By default, stderr simply discards anything that's written to it. On a POSIX-like system, you'd be able to use dup2() to replace the underlying file descriptor. This wouldn't work on CloudABI, because stderr is not attached to file descriptor 2. File descriptor 2 has no special meaning. It can be used arbitrarily.

ISO C provides the freopen() function that could be used to redirect stderr, but just like fopen(), we can't implement it in a meaningful way. This is why cloudlibc provides a generalization of freopen(), called fswap():

void fswap(FILE *, FILE *);

This function can be used to swap the state of two FILE objects. Below is an example of how it may be used in practice:

#include <argdata.h>
#include <assert.h>
#include <program.h>
#include <stdio.h>
#include <stdlib.h>
#include <syslog.h>

void program_main(const argdata_t *ad) {
  // Reconfigure stderr.
  int fd;
  if (argdata_get_fd(ad, &fd) == 0) {
    FILE *f = fdopen(fd, "w");
    if (f != NULL) {
      fswap(f, stderr);
      fclose(f);
    }
  }

  // Write various things over stderr.
  fprintf(stderr, "I am now going to crash.\n");
  syslog(LOG_INFO, "Also logging that I'm going to crash.");
  assert(0 && "Crashing!");
  fprintf(stderr, "Assertions disabled?\n");
  exit(1);
}

And here is what it looks like when invoked:

$ x86_64-unknown-cloudabi-cc -o bla bla.c
$ cat bla.yaml
%TAG ! tag:nuxi.nl,2015:cloudabi/
---
!fd stdout
$ cloudabi-run bla < bla.yaml
I am now going to crash.
2019-01-01T21:57:19.636344863Z INFO      Also logging that I'm going to crash.
bla.c:21: assertion failed in program_main(): 0 && "Crashing!"
zsh: abort      cloudabi-run bla < bla.yaml

Hope that helps!

@EdSchouten Thank you for the tip! assert() definitely works as long as stderr is remapped to the stderr file descriptor configured in YAML.

Say, could we flesh out some similar printf(), puts(), putchar(), implementations, so that users have the option of remapping stdout as well?

I'm not convinced we should add those. Looking at the bulk of library C/C++ code out there, you see that stdin and stdout are not used that often. When they are, it is often used accidentally or in bad taste. You do see that stderr is used quite often, typically for logging events/errors that happen in the background. This, together with what's discussed above, is the reason why only stderr is provided.

Within user-interactive applications (e.g., UNIX shell tools) you do see stdin and stdout being used quite often. So far the focus hasn't really been to bring those over to CloudABI in close to unmodified form. For those applications, the absence of stdin and stdout is a nuisance compared to other things that are missing (e.g., open()). I therefore think it it would make more sense to have stdin, stdout, printf(), scanf(), etc. part of a compat layer as mentioned here.

Well in that case, let's at least offer an assert_fd() with a stream parameter, so that our users can enjoy easily integrating assertions in their codebases with cloudlibc!