Implement VOLK_strerror #24
Labels
No labels
area/api
area/codec
area/framework
area/integrity
area/performance
area/store
area/tools
p
critical
p
high
p
low
p
normal
t
bug
t
documentation
t
enhancement
t
feature
t
test
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
ktx/volksdata#24
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Currently VOLK functions may either return a
VOLK_rctype value which is a return code, or another type which is the actual data requested by the caller. In the latter case, it is hard to report precise errors: e.g., by of returning NULL where a new struct handle is expected, which can be detected as an error but does not tell the caller anything about what went wrong. For functions returningsize_t,bool, etc. this is even less informative.Some libraries such as LMDB have chosen to consistently return an rc, and use a pointer value in the function signature to yield new data. This is not practical for this project, as it would make implementation code much more cumbersome to write: e.g. one would have write something as common as
thus instead:
As a compromise between being informative, consistent and easy to use, VOLK functions could be divided into two categories:
VOLK_rctype (no change to the ones that already do so);VOLK_errnovalue on error (in this case the return value would be undefined and should not be used by the caller).VOLK_strerrorshould use the same codes already in use.This systems makes it easy to memorize which functions should be checked for rc, and which for strerror, and can yield precise information about the failure.
This feature requires two new set of macros in the
RCCK,PRCCK, etc. family to check forVOLK_strerrorinstead of the function rc. To avoid the proliferation of these macros, which are already hard to memorize, some consolidation may be beneficial, e.g.:CALLOC_GUARDandMALLOC_GUARD(already inflexible) and replace their calls with malloc / calloc + NLRCCK or NLNL