Inconsistent use of booleans in various parts of Elektra.


\begin{DoxyItemize}
\item needs to be string
\end{DoxyItemize}


\begin{DoxyItemize}
\item only check presence or absence (no cascading override of already present key possible)
\item use booleans as in C\+Make, which allows on/off, true/false, ... (would need convenience across the code)
\item do not accept a specification with {\ttfamily type = boolean} without a default
\end{DoxyItemize}

Only the strings {\ttfamily 0} and {\ttfamily 1} are allowed in the {\ttfamily Key\+Set} for {\ttfamily type = boolean}, for both values and defaults. Everything else should lead to errors in checkers (in {\ttfamily kdb\+Set}).

A spec with {\ttfamily type = boolean} without a specified default should be interpreted as {\ttfamily default = 0}.

Example for an implementation in C in an application\+:


\begin{DoxyCode}
\textcolor{keywordflow}{if} (k != NULL && strcmp(\hyperlink{group__keyvalue_ga880936f2481d28e6e2acbe7486a21d05}{keyString}(k), \textcolor{stringliteral}{"1"}) == 0) \{\textcolor{comment}{/*true*/}\} \textcolor{keywordflow}{else} \{\textcolor{comment}{/*false*/}\}
\end{DoxyCode}


Storage plugins are allowed any representation as suitable, e.\+g., a J\+S\+ON plugin might render {\ttfamily 1} as {\ttfamily true}.

The type checker plugin should allow


\begin{DoxyItemize}
\item non-\/presence
\item the string \char`\"{}0\char`\"{}
\item the string \char`\"{}1\char`\"{}
\end{DoxyItemize}


\begin{DoxyItemize}
\item most easy to implement
\item allows non-\/presence to be false
\item plugins allow us to convert to any other behavior
\end{DoxyItemize}


\begin{DoxyItemize}
\item Storage plugins are only allowed to emit {\ttfamily 0} or {\ttfamily 1} as key values
\item Applications either get {\ttfamily 0} or {\ttfamily 1}, or (without a key) can safely assume that false is meant
\end{DoxyItemize}