| Elektra 0.11.0

Definition of Bool

# Problem

Inconsistent use of booleans in various parts of Elektra.

# Constraints

- needs to be string

# Assumptions

# Considered Alternatives

- only check presence or absence (no cascading override of already present key possible)
- use booleans as in CMake, which allows on/off, true/false, ... (would need convenience across the code)
- do not accept a specification with `type = boolean` without a default

# Decision

Only the strings `0` and `1` are allowed in the `KeySet` for `type = boolean`, for both values and defaults. Everything else should lead to errors in checkers (in `kdbSet`).

A spec with `type = boolean` without a specified default should be interpreted as `default = 0`.

Example for an implementation in C in an application:

if (k != NULL && strcmp(keyString(k), "1") == 0) {/*true*/} else {/*false*/}
keyString
const char * keyString(const Key *key)
Get a pointer to the c-string representing the value.
Definition keyvalue.c:208

Storage plugins are allowed any representation as suitable, e.g., a JSON plugin might render `1` as `true`.

The type checker plugin should allow

- non-presence
- the string "0"
- the string "1"

# Rationale

- most easy to implement
- allows non-presence to be false
- plugins allow us to convert to any other behavior

# Implications

- Storage plugins are only allowed to emit `0` or `1` as key values
- Applications either get `0` or `1`, or (without a key) can safely assume that false is meant

# Related Decisions

# Notes