Re: Way to override/overload D’s runtime assertions to use custom handlers?
On Wednesday, 25 July 2018 at 15:24:50 UTC, Alexander Nicholi
wrote:
Is there a way to change this to use our own handlers with the
D runtime?
You can provide your own implementations of the runtime hooks at
https://github.com/dlang/druntime/blob/cb5efa9854775c5a72acd6870083b16e5ebba369/src/core/exception.d#L628
extern(C) void _d_assertp(immutable(char)* file, uint line)
{
import core.stdc.stdio;
printf("Houston, we have a problem at %s:%u\n", file, line);
}
void main()
{
assert(false);
}
Try it out at https://run.dlang.io/is/QZEO9W
How does this change without the runtime, e.g. via `-betterC`
code?
Unfortunately, this doesn't work with -betterC because -betterC
seems to forward runtime assertions to the C implementation. See
https://run.dlang.io/is/QZEO9W
For that you have to provide a new implementation of `__assert`:
extern(C) void __assert(const char *msg, const char *file, int
line)
{
import core.stdc.stdio;
printf("Houston, we have a problem at %s:%u\n", file, line);
}
extern(C) void main()
{
assert(false);
}
https://run.dlang.io/is/D5JxCT
Mike
Re: Way to override/overload D’s runtime assertions to use custom handlers?
On Wednesday, 25 July 2018 at 15:24:50 UTC, Alexander Nicholi
wrote:
Hello,
A project I’m helping develop mixes D code along with C and
C++, and in the latter two languages we have custom macros that
print things the way we need to, along with app-specific
cleanup tasks before halting the program. Because it uses
multiple languages, two of which have spotty or nonexistent
exception support, and because we only depend on the D runtime
sans libphobos, we have opted to avoid the use of exceptions in
our codebase. Assertions still give us the ability to do
contract programming to some extent, while C++ and D provide
static assertions at compile-time to supplement.
With runtime assertions, C and C++ handle things amicably, but
D’s `assert` builtin seems to fall back to C99’s assert.h
handlers and there doesn’t seem to be a way around this. Is
there a way to change this to use our own handlers with the D
runtime? How does this change without the runtime, e.g. via
`-betterC` code? If not, is this something that can be
implemented in the language as a feature request? Our use case
is a bit odd but still a possibility when using D as a
systems-level language like this.
Thanks,
Alex
As far as I know, D's "assert" falls back to __assert. I have a
pet/educational project (github.com/marler8997/maros) where I
don't use the D runtime or the C runtime and my definition looks
like this:
extern (C) void __assert(bool cond, const(char)[] msg)
{
// TODO: would be nice to get a stack trace
if (!cond)
{
version (linux)
{
import stdm.linux.file : stderr, write;
import stdm.linux.process : exit;
}
else static assert(0, __FUNCTION__ ~ " not implemented on
this platform");
write(stderr, "assert failed: ");
write(stderr, msg);
write(stderr, "\n");
exit(1);
}
}
I just put this in my "object.d".
Way to override/overload D’s runtime assertions to use custom handlers?
Hello, A project I’m helping develop mixes D code along with C and C++, and in the latter two languages we have custom macros that print things the way we need to, along with app-specific cleanup tasks before halting the program. Because it uses multiple languages, two of which have spotty or nonexistent exception support, and because we only depend on the D runtime sans libphobos, we have opted to avoid the use of exceptions in our codebase. Assertions still give us the ability to do contract programming to some extent, while C++ and D provide static assertions at compile-time to supplement. With runtime assertions, C and C++ handle things amicably, but D’s `assert` builtin seems to fall back to C99’s assert.h handlers and there doesn’t seem to be a way around this. Is there a way to change this to use our own handlers with the D runtime? How does this change without the runtime, e.g. via `-betterC` code? If not, is this something that can be implemented in the language as a feature request? Our use case is a bit odd but still a possibility when using D as a systems-level language like this. Thanks, Alex
