I don't know what the question is. You can `git grep PETSC_ERR_PLIB` for
places where we are checking for corruption in something that PETSc has
produced. When those checks are expensive (like checking if indices are
sorted), they use `if (PetscUnlikelyDebug(cond)) { ... }` or `if
(PetscDefined(HAVE_DEBUG)) { ... }`.
Jacob Faibussowitsch <[email protected]> writes:
> Hello All,
>
> How far should one go in error checking when using #if
> defined(PETSC_USE_DEBUG)? So far I have gone with the mantra that internal
> petsc routines (including ones authored by myself) should be considered
> infallible and that I should only be checking for garbage *input* from the
> user. But there is not a person in existence that doesn’t write buggy code,
> as evidenced by the somewhat routine “fixing bug in XYZ” merge requests one
> sees.
>
> On the other hand it is also not reasonable to check every single output with
> a fine-tooth comb because for the majority of cases code written by petsc
> developers is working as intended. Take for example writing an array sorting
> algorithm. Since every operation is "performance critical” these are often
> written in less logical or less readable formats leading to some subtle bugs
> that the writer doesn’t immediately catch. If these remain uncaught through
> CI/CD and then bleeds into a user code I see absolutely no chance of the user
> (or even other devs) ever being able to identify that the sorting algorithm
> deep in some function stack is the one producing the bug without significant
> effort. One could include a “dumb” version of the same algorithm that checks
> a copy of the initial array for missing/misplaced elements but as mentioned
> above this is a pointless slowdown 99% of the time.
>
> CI/CD -- while excellent at catching a lot of machine-specific bugs -- isn’t
> bulletproof either. It relies on the assumption that the writer knows all
> possible sources of bugs in their code and provides a test case for each, but
> to quote Isaac Newton “what we know is a drop, what we don’t know is an
> ocean”. I have been mulling over this problem for a while now, and have
> looked through the user manual/developers manual but have not found a
> definitive answer.
>
> Best regards,
>
> Jacob Faibussowitsch
> (Jacob Fai - booss - oh - vitch)
> Cell: (312) 694-3391
