Hi -
> [...]
> > Some questions. Why do we pad at all?
>
> PDUs are multiples of an int .. so that's why we're padding here.
No big deal, but why are PDUs multiples of an int? It may matter for
the archive format, but for network & other temporary purposes, does
the multiples-of-an-int property carry any benefit?
> [...] I can't see the place in pducheck.c that is making
> assumptions about padding ... can you explain that to me?
(Just that the qa/367{,.out} files assert '~' padding in a bunch of
places.)
> [...] If we need/want to fix it libpcp, then your suggested patch is
> fine by me ... '~' is perhaps a little clearer than 0x7e and matches
> what we do elsewhere in similar cases.
Righto, thanks for the pointer. Please see pcpfans.git
commit 0a28107318939e2a28540efa1d8934e58dce6a32 (HEAD, origin/fche/multithread,
fche/multithread)
Author: Frank Ch. Eigler <fche@xxxxxxxxxx>
Date: Mon Mar 9 09:40:10 2015 -0400
pdubuf padding: unconditional & for p_pmns too
Teach SendNameReq to initialize the '~'-padded last few bytes of its
output pdubuf, an absence that was caught with the prexisting
qa/{367,386} tests with the prototype minimally-sized pdubuf code.
Elsewhere nearby in libpcp where '~'-padding is in use, drop the
padding is a potential security problem.
- FChE
|