When feh loses its controlling terminal at runtime, e.g. due to backgrounding /
disowning, it will no longer issue a warning on each terminal keystroke.

This allows finer control of which files are compiled and additionally
will silence some -Wpedantic warnings when "empty" files are compiled.

As there's no "default" window, it doesn't make much sense here...
Plus, it's buggy as hell in this mode

Also, restore the previous terminal mode on exit

Turns out that it is undefined behaviour to pass a value to isctype functions
which does not fit inside a char. Closes #312

(cf #309)

Closes #303

If malloc cannot allocate enough memory, it could return NULL. This is
not necessarily true for default Linux settings, but can be provoked
there as well by adjusting proc entries. Other systems like the *BSD
ones definitely do this.

The function _emalloc exists for exactly this purpose, so use it instead
of calling malloc directly.

Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>

If feh_unique_filename encounters a file that already exists, the memory
for the temporary filename is not released. As this happens in /tmp at
some code places, an attacker could use this to spray the memory of feh,
or simply triggering an out of memory condition.

Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>

If ereadfile encounters an empty file or the file could not be read, an
out ouf boundary read (and possible write) occurs. Always check the
return value of fread to be > 0 before processing the result buffer.

Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>

The strncpy function does not guarantee to end the resulting character
sequence with a terminating nul character if not enough space is
available. This could be triggered by supplying a sufficiently long
output_file option.

Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>

If a malicious client pretends to be the E17 window manager, it is
possible to trigger an out of boundary heap write while receiving an
IPC message.

The length of the already received message is stored in an unsigned
short, which overflows after receiving 64 KB of data. It's comparably
small amount of data and therefore achievable for an attacker.

When len overflows, realloc() will either be called with a small value
and therefore chars will be appended out of bounds, or len + 1 will be
exactly 0, in which case realloc() behaves like free(). This could be
abused for a later double-free attack as it's even possible to overwrite
the free information -- but this depends on the malloc implementation.

Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>

like %o and %z in slideshow actions (I would like to use this to zoom in, pan,
and then use an action to crop the window to zoomed in view).