we want to be able to access either all outputs, or the currently
selected one (if any, else return the top one, which ought to be the GUI
one if we have one).
Hopefully this will lead the way to adding support for things like
Wayland and Haiku graphics, cf. #56.
We define a display_output_base class that display backends
can derive from to implement display-specific calls.
This change corrects dependencies on generated defconfig.h and/or
convertconf.h header files because they must be generated before
compilation of conky.cc and main.cc if BUILD_BUILTIN_CONFIG and/or
BUILD_OLD_CONFIG are set.
Fixes: https://github.com/brndnmtthws/conky/issues/1118
Retrieve graph only when s->graph is already allocated, which also mens
that the s->graph_width is bigger than 0, and thus avoid out-of-bounds
write in graph_append function.
Prior to 594d0c85ba ("Fix bug of "Graph reset when using conditional
color"") s->graph was not (re)allocated when s->graph_width and
s->graph_allocated were equal to zero, therefore, s->graph stayed equal
to nullptr. This effectively meant that graph_append function returned
immediately after call and did nothing.
This behavior changed with introduction of std::map<int, double *> graphs,
because its retrieve_graph support function allocates s->graph even for
s->graph_width equal to 0. Then, subsequent call of graph_append can
continue and the first element of the graph is set later in this
function in line:
graph->graph[0] = f; /* add new data */
causing out-of-bounds write, as there is not enough space in array of
zero length. This write messes up internal data of memory allocator (at
least in musl libc case) and the application later segfaults in attempt
to free this memory in store_graph function.
Fixes: 594d0c85ba ("Fix bug of "Graph reset when using conditional color"")
It's not quite clear to me what the intent was here, but I don't believe
this change was correct. We shouldn't block on callbacks within the main
loop.
This fixes #901.
