send.c:_print_part_info(): fix buffer overflow (Gavin Troy, Thomas)..

send.c:_print_part_info(): fix buffer overflow (Gavin Troy, Thomas)..

A bug note on the ArchLinux bug tracker [1] i couldn't reproduce.
Thanks to the insisting reporter Thomas (wasd AT gmx DOT net)
i finally digged a bit deeper and found an off-by-one (actually it
seems that i was overoptimizing, yet forgot that one line later).
I think that Gavin Troy reported the same bug through the flower
more than seven months ago (besides reporting another one in
words), but the problem simply doesn't show up on BSD.

  [1] <https://bugs.archlinux.org/task/37950>

'Must be said: our internal (mine mine mine) memory pool does
the following, and, with it, finding that bug would have been
a matter of looking at the mail.  Sigh.

        // upper hope
        if(*r(ui4*,x.ui1p+u.e->alloc) != _HOPE) {
                Log::lock();
                Log::write(Log::alert,
"%s(%P): \"upper hope test\" failed.%R"
"\tThis means that you have violated upper bounds.%R"
"\tPointer last seen: file %s, line %hu.%R",
                        _func, _ptr, u.e->file, u.e->line);

                if(!_LAST_HOPE(*r(ui4*,x.ui1p+u.e->alloc)))
                        Log::write(Log::emerg,
"%s(%P): \"last upper hope test\" failed.%R"
"\tYou've violated upper bound GT 2 bytes.%R"
"\tMay cause problems for upper alloc later on...%R",
                        _func, _ptr);
                else
                        Log::write(Log::alert,
"%s(%P): \"last upper hope test\" succeeded.%R"
"\tYou've violated upper bound LE 2 bytes.%R",
                        _func, _ptr);
                Log::unlock();
                ret = fal0;
        }