RE: [PATCH 01/33] libsepol: basic serilization support

[James Antill <jantill@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]

On Wed, 2007-04-25 at 12:25 -0400, Joshua Brindle wrote:

> So move boiler plate casting and checking to the call site? I guess we
> can do that... :\

 Having a wrapper that does it for you isn't such a bad thing, and
calling that wrapper serialize_sizet/unserialize_sizet or whatever isn't
the worst thing in the world[1].
 The problem, from my POV, is that you check on the receiving side if
size_t happens to be bigger than uint32_t[2]. You are basically sending
a uint64_t over the network that can never hold a value bigger than a
uint32_t, so everything gets to send extra zeros. This is very
misleading, just say what you mean by having the protocol use uint32_t,
and check at the sending side if the value > uint32_t can hold, if so
error in some way.

 Dito with SERIAL_STRING (although that probably fails by accident
atm.), just fail to ever send "large" strings, and use uint32_t for the
length. You should probably also pick a limit on receive instead of
hoping calloc() will save you.


[1] Although an interface name that makes it obvious the size_t is going
to be down converted to uint32_t would be better.

[2] Well it actually uses (unsigned int), via. UINT_MAX, which is
another bug as it should be using UINT32_MAX from stdint.h.

-- 
James Antill <jantill@redhat.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]