Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add documentation for using assertions. #502

Merged
merged 1 commit into from
Apr 10, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Binary file modified source/doc/coding_rules/opener_coding_rules.pdf
Binary file not shown.
62 changes: 61 additions & 1 deletion source/doc/coding_rules/src/opener_coding_rules.tex
Original file line number Diff line number Diff line change
Expand Up @@ -246,4 +246,64 @@ \section{Code Formatting}
In order to have consistent code formating the Google C++ coding style rules shall apply. When using Eclipse as development environment the coding format xml file is available at \url{https://github.com/google/styleguide}. By pressing \verb|<ctrl><shift>f| the formatter will format the code according to these rules.


\end{document}
\section{Assertions}
The \lstinline!OPENER_ASSERT(e)! macro is available for traditional
assertion checks, halting the program if the expression provided as the
argument \lstinline!e! evaluates false. This macro shall \emph{only} be used
to test conditions where the only possible cause of failure is an
unquestionable bug with this program, typically leading to undefined behavior
or a crash if execution were permitted to continue.
In other words, an assertion shall \emph{never} fail
as a result of any external input, valid or invalid,
or other similar foreseeable condition, such as a memory allocation failure.
These latter type of failures must be handled by normal code execution paths
that yield responses with appropriate error codes or possibly
terminating the program with a non-zero exit code, not an assertion failure.

The following listing of a function to set an attribute's value based
on received data is an example to help illustrate proper use of assertions.
The \lstinline!raw! and \lstinline!len! parameters
refer to the received data and length, and the \lstinline!foo! parameter
points to the target attribute; the function returns true only if the attribute
was set successfully.

\begin{quote}
\begin{lstlisting}
bool SetAttributeFoo(const void *raw, size_t len, CipDint *foo) {

/*
* This function should never be called with NULL pointers, regardless of
* what was received over the network, so assertions should be used to
* validate the pointer arguments.
*/
OPENER_ASSERT(NULL != raw);
OPENER_ASSERT(NULL != foo);

/*
* Ensuring enough data was received to satisfy the target data type
* must not be done with an assertion as a malformed message containing
* insufficient data shall not halt the program.
*/
if (sizeof(CipDint) > len) {
return false;
}

CipDint new_value = &(int *)raw;

/*
* Here the received value is tested for conformance to acceptable values;
* assume for the sake of this example that allowable values are nonzero.
* Validating values received from external sources must not be done
* with assertions.
*/
if (0 == new_value) {
return false;
}

*foo = new_value;
return true;
}
\end{lstlisting}
\end{quote}

\end{document}
Loading