Handling out of bounds requests in embedded C library

Question

We're currently building a library in C that configures itself from tables in EEPROM.

This leaves the possibility however that some caller requests a field that is out of bounds, and the question then is, what can we do about that?

We've been thinking about an optional here, but since we're implementing our own error code, the caller has to actively remind themselves to to check this value, making it easy to miss.
Another option would be to just crash the system, which would prevent the system from running with an invalid configuration, but that would be undesirable because that could put the system into a boot-loop and it would trip up our unit-test system.
Having an enum limiting the input options could also work, were it not that we don't know ahead of time how many entries will be in the tables, and the enum would produce a lot of clutter.

Does anybody have any other ideas on how to handle this?

What kind of library are you writing? Is it a kind of wrapper around the EEPROM that doesn't have knowledge of what is stored there, or is the functionality of the library not related to the EEPROM and the fact that the library uses EEPROM for persistent storage is of no direct consequence to the users of the library? — Bart van Ingen Schenau, Commented Aug 21, 2017 at 10:01
@BartvanIngenSchenau The code reads the configuration from EEPROM, but the EEPROM implementation is handled by another piece of code. This library is just trying to make sense of what is stored in the persistent memory and make that available to the rest of the application. It doesn't concern itself with the bits on the wire though. — bemk, Commented Aug 21, 2017 at 10:29

Doc Brown · Accepted Answer · 2017-08-21 13:58:08Z

since we're implementing our own error code, the caller has to actively remind themselves to to check this value, making it easy to miss.

Why not design the API in a way it becomes hard for the caller to miss an error?

For example:

design your function in a way it does not only return the result of the operation, but also explicitly an error code (for example, by an additional "out" parameter, or by returning a struct value with a combination of result & error code, instead of a primitive type)
make a clear statement in the API docs that this error code has to be checked

Make it also easy for the caller to find out about the correct bounds:

provide a function in the API to retrieve the correct upper bound (and also for the lower bound, if it is not always zero) at run time
give an example in the docs how this function should be used correctly.

This is probably all you can do here. If then a caller still ignores the error code and also ignores the bounds function: not your fault.

1 Answer 1