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()
andpsignal()
, - 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!