Non-consistent exit statuses

[prj-]

The exit statuses of functions are non-consistent in the library, e.g., MMG2D_Set_meshSize returns 1 on success, while MMG2D_mmg2dlib returns MMG5_SUCCESS (defined to 0) on success. Would it be possible to follow the standard and always return 0 (or MMG5_SUCCESS) on success? Otherwise, it makes error checking in calling libraries extremely difficult to handle, see, e.g., https://gitlab.com/petsc/petsc/-/merge_requests/4889#note_863666426, as one needs to jump back and forth between if (return code != 1) // calling-library custom error-handling and if (return code != 0) // calling-library custom error-handling.

[prj-]

If you do not plan on addressing this in the near future, could you please generate two parsable lists of functions: the ones that return MMG5_SUCCESS on success and the ones that return 1 on success?

[Algiane]

Hi,

Really sorry for the bad choice of API design: when I start working on Mmg, the convention inside Mmg was to return 1 on success and 0 on failure and the software was already interfaced in external software so I have developed APIs with respect to this convention.

I know that the philosophy is criticizable but at least it follows a kind of rule:

• Main library fonctions (MMG<X>_mmg<x>lib, MMG<X>_mmg<x>ls, MMG<X>_mmg<x>mov and MMG2D_mmg2dlib) return MMG5_SUCCESS, MMG5_STRONGFAILURE (for non conformal mesh) and MMG5_LOWFAILURE (for non completed remeshing);
• All other API that may be used to set/get the mesh or to configure the parameters returns 0 or -1 on failure (0 most of time), 1 on success.

Honestly, I don't want to engage myself in modifications that will impact all the people that link with Mmg without consulting at least the members of the consortium (for me, such kind of modifications should be part of a major release but I will not have the time to prepare in a clean way such kind of release).

I will look to create the parsable lists of functions, thanks for the proposition!

Best Regards