On 2016-11-23 16:03:44 +0000, Yuri Gribov wrote:
> Definitely, aggressively abusing assertions like this should be a
> per-project decision. E.g. I've seen code which parallels assertions
> with error checking i.e. something like
> FILE *p = fopen(...);
> assert(p); // Quickly abort in debug mode
> if (!p)
> return ERROR;
> Enabling __ASSUME_ASSERTS__ for such code would effectively disable
> all safety checks.
Yes, the problem comes from the fact that ISO C provides only one
form of assertions. In GNU MPFR, we have two kinds of assertions
(different from the one used above), but they are not based on
assert():
MPFR_ASSERTN(expr): assertions that should normally be checked,
otherwise give a hint to the compiler.
MPFR_ASSERTD(expr): assertions that should be checked when testing,
otherwise give a hint to the compiler.
Basically, MPFR_ASSERTN() will be used to do some checks on data
provided by the caller (e.g. to detect some API misuse), and
MPFR_ASSERTD() is there to detect internal inconsistencies (i.e.
bugs in MPFR).
IMHO, this is the correct way to do, as one can then enables hints
without breaking code like the above one.
Concerning the "per-project decision", I'm not sure that's a good
idea: as soon as one includes a header file, __ASSUME_ASSERTS__
could potentially break code. Said otherwise, if the user wants
optimization hints, it should not be based on assert().
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
