Proposal: Add TEST_EXCEPTION for C

[RosscoG]

TEST_EXCEPTION Features for C

Hi all,
I’ve been working on extending Acutest with a TEST_EXCEPTION for C, enabling exception-like tests just like the C++ ones. I always want tests for asserts and/or other non-zero exit conditions. Generally I end up with a block of tests that I uncomment every now and then to make sure they fail. I'm over this and at seeing "SHOULD FAIL" comments all over the place, so I'm going to do something about it.

I am currently focusing on the windows side of things, but will make it cross platform in the end. It's all pretty rough while I hack it out. I'll clean up and make a draft PR for your perusal soonish.

Sample of output so far, warts and all. The stderr output from exit is messing the lines up, but I'll get to that eventually.

---

Feature Overview

1. New Macros for C:

   • TEST_EXCEPTION(code, expected_exit_code):
     Verifies that the provided code results in the expected exit condition (e.g. access violations, seg faults, custom signals), following the style of the C++ macros.
   • TEST_EXCEPTION_:
     A variant that allows for a custom message, again, same style as the C++ ones.

2. Platform-Specific Support:

   • Windows: Handle SEH exceptions and match them against expected codes.
   • Unix: Use signals to detect exceptions and validate exit codes.

---

Request for Feedback

1. Feature Scope:

   • Does adding TEST_EXCEPTION for C make sense and align with acutest goals?
   • Are there any concerns about adding platform-specific handling?

2. Implementation Considerations:

   • Is mirroring the C++ API (TEST_EXCEPTION, TEST_EXCEPTION_) clear and consistent in style?
   • Is using shared memory acceptable? I'm trying to keep it encapsulated and simple, but I understand its a big addition for one feature(though no external dependencies of course).
   • Are there non shared memory ideas/solutions that I could/should have used?
   • Suggestions for additional use or edge cases to handle?

---

Next Steps

If acceptable, I’ll:

1. Finalize the feature implementation and clean up my fork.
2. Submit a pull request with accompanying tests and documentation.

---

[RosscoG]

This is probably duplication of closed issue #31.
I just stumbled over it but I'm sure I looked for discussion on this originally, sorry.
I will think further on Martins comments from that issue. If I can make a case for it, I'll push my solution and lay the justification out. It does come with some pretty heavy implications though (eg shared mem between processes), so it'll be a pretty hard sell.

I still like the feature, so no loss. I have my version to use when hacking out stuff that I want to make sure crashes intentionally. Some code should be used gingerly. When it is a lib that can't back out gracefully, I need to know that I'm misusing it mediately.

[yairlenga]

@RosscoG - I've opened #86 with ideas on implementation paths - at least one is similar to what you have suggested. I hope that it will get reviewed/feedback that might lead to implementation - looks like your proposal is practically "on hold".