Design a way to expose internal error states for debugging

[thirtytwobits]

As is appropriate for libudpard, the error system exposed to applications is very simple. There are times, however, when deeper introspection would be helpful. For example, when first integrating with a system the integrator is likely to make a few mistakes that are atypical for a healthy system but which are common misconceptions or just dumb mistakes caused by the tendency of many to read variable names instead of documentation. There are not many of these conditions in our simple code base which makes it undesirable to design a normal error scheme to support this use case. One idea is to provide a -DDEBUG enabled structure that can store this type of error data when enabled (e.g. sort of a posix errno scheme). Other ideas are welcome but the end result would be to make libudpard a bit more friendly to new users.

[pavel-kirienko]

Scott's comment from #38

I don't know. Perhaps I'm overcomplicating things but there's just a lot of great error information that gets lost in this code I want to capture somehow. Perhaps just an errno scheme where we never require the user to use the static error data (i.e. we always provide a return value UDPARD_ERROR_ when needed) but we can stuff our data into that field if anybody cares?

I like the errno idea. We can define a global thread_local uint_fast16_t g_udpard_diagnostic_line and update it from anywhere within the library unless UDPARD_NDEBUG is defined. The user is free to leverage this information or ignore it. Instead of maintaining a separate set of diagnostic codes, we could try this radical way of using the line number:

if (is_disaster)
{
    g_udpard_diagnostic_line = __LINE__;
}

Since this is not for production use, the __LINE__ numbers don't have to retain consistency across releases; their advantage is that they immediately provide visibility of the context where the problem was observed.

Up until now I believed this to violate MISRA C:2012 but looking at the standard now I don't see anything that would prohibit a conditionally provided global thread-local variable. Am I missing something?