On Mon, Sep 8, 2025 at 3:40 AM John Dallman <jgdatsiem...@gmail.com> wrote:
> > Is the test harness and the library-under-test designed to be compiled > into the > > same executable? > > Yes. We prefer to have the library-under-test be a shared object or > Windows DLL, on platforms where that's possible, but we can have the > harness and the library linked together, and that's what I'm planning to do > for WebAssembly. I'm trying to avoid producing a JS wrapper for an API with > hundreds of functions, hundreds of structs, and thousands of constants. It > also passes lots of pointers to code and data through the interface. My > customers who want a WebAssembly version of the library already have C/C++ > or Swift code that calls it and want to use it that way. > > > i.e. on other platforms does it somehow catch and recover from sefaults? > > Yes.On platforms with signals, those are turned on for segmentation faults > (and for some other signals, depending on the platform). The code is C, > which sets regular checkpoints with setjmp() and the signal handling > function longjmp()s to the latest checkpoint with a "test aborted" value. > That's the basic idea, though it's rather more complicated in practice. > Oh wow, `longjmp` out of your signal handler sounds pretty gnarly. It's going to be even more gnarly trying to make that work with emscripten-generated code, but maybe not impossible? Are there segfault tests limited in number? i.e. would it be possible to choose a different approach when running on the web (just for these few tests)? > > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CAL_va29k6i8g7T-eb4Jor%2BhUTO5ia70SfYUfn85vthfzGG%3D%2BOg%40mail.gmail.com.
