Hi Andrew,

 > Elsewhere in the code we treat messages with too few / missing FDs as
> valid and I think I commented on this in one of the commit messages,

git show 439e259835d8b2788ca28c1dbe06badbd178dccf

This one only deals with num_fds > L_ARRAY_SIZE(message->fds), which 
makes sense.

git show 1e1aa1aa63be7b50a4d35aa01d14c001bf591fd1

Also sort of makes sense...

> another thing to consider is that we currently hardcode an FD limit of
> 16 per message and will happily generate such messages ourselves.  So
> the code can handle the situation when unix_fds > num_fds and there's
> nothing specific we have to do unless we decide to make it an error.

Which I think we should by the way.  If the message tells us we have 3 
fds, and we only receive 1 or 0, then that should be fatal.  It would 
most likely indicate an error in our transport code logic.  I'd actually 
like to make this verbose and see if this ever happens.  AFAIK, 
dbus-daemon does not allow this.

Since kdbus uses message_from_blob and dbus-1 uses message_build, do you 
want to have different constraints between those two?

>
> If we want to be really smart about queuing up FDs in a circular
> buffer to assign to messages by unix_fds value then we would probably
> want a separate function that would take a header and just return the
> unix_fds value.

I was hoping we could avoid that via use of MSG_WAITALL.  I suspect 
you're right and we need to.

Regards,
-Denis