All of lore.kernel.org
 help / color / mirror / Atom feed
* unix(7) and MSG_TRUNC semantics
@ 2007-01-11 14:41 Daniel Kabs
  0 siblings, 0 replies; only message in thread
From: Daniel Kabs @ 2007-01-11 14:41 UTC (permalink / raw)
  To: linux-kernel

Hello!

For IPC, I use unix domain datagram sockets. I receive messages by calling 
recv(). The man page recv(2) tells me about the flags argument to a recv 
call, namely:
 MSG_TRUNC
      Return  the  real  length of the packet, even when it was longer
      than the passed buffer. Only valid for packet sockets.
Thus I used recv() with flags MSG_TRUNC|MSG_PEEK in order to detect 
message truncation due to insufficient buffer size.

Strangely enough, MSG_TRUNC seems to get ignored by the kernel: If the 
message received is larger than the receive buffer I supplied, the 
function returns the size of the buffer. I reckon, the function should 
return the real message size instead.

To work around this problem, I use the ioctl FIONREAD instead.

On the other hand, in this mailing list, I found an old bug report 
describing the same problem using UDP sockets:

http://groups.google.com/group/fa.linux.kernel/browse_frm/thread/fb6acbb527507e26/ad0b2ba33b6b66fa

UDP sockets seem to have been patched by now. From linux/net/ipv4/udp.c:
 udp_recvmsg()
  ...
        err = copied;
        if (flags & MSG_TRUNC)
                err = skb->len - sizeof(struct udphdr);
   ...

Why doesn't unix_dgram_recvmsg() in linux/net/unix/af_unix.c contain code 
to this effect? Is this a feature or a bug?


Cheers
Daniel Kabs

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2007-01-11 15:00 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-01-11 14:41 unix(7) and MSG_TRUNC semantics Daniel Kabs

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.