Fix double-free/OOB-write while receiving IPC data

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).

This reverts commit 465238bd.

Fixed(?) Makefile document build issue for README.md

Convert README to markdown

Looks prettier

Fix FSF address

On some systsems sysconf() can return a very large value, unsuitable for
use with malloc().  Only use sysconf() if HOST_NAME_MAX isn't avalable.

FreeBSD lacks the constant HOST_NAME_MAX, instead using sysconf(3) to
find out the value of the maximum host name length at run time.  Patch
to use this instead of HOST_NAME_MAX.
This brings with it the need to use malloc instead of using a statically
sized buffer for the host name, since the size of the buffer cannot be
known at run time.  Errors from sysconf or malloc just means that the
entire block of code is skipped over (the same way it's skipped if the
call to gethostname() fails), rather than returning any kind of error to
the caller or logging an error message somewhere.