netdev - Documentation RFC: MSG_TRUNC and TCP sockets

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <cfd18e0f0812010816m5c8a689t2c28421d1bcdac84@mail.gmail.com>
Date:	Mon, 1 Dec 2008 11:16:01 -0500
From:	"Michael Kerrisk" <mtk.manpages@...glemail.com>
To:	netdev <netdev@...r.kernel.org>,
	"David Miller" <davem@...emloft.net>,
	"Stephen Hemminger" <shemminger@...ux-foundation.org>,
	"Andi Kleen" <andi@...stfloor.org>
Cc:	"Hamish Moffatt" <hamish@...ian.org>, linux-man@...r.kernel.org
Subject: Documentation RFC: MSG_TRUNC and TCP sockets

After a bug report from Hamish, I did some reading to determine
meaning of MSG_TRUNC for TCP sockets.  I'd appreciate confirmation
that the following text, scheduled the tcp(7) page in man-pages-3.15,
matches reality, and the developers' intentions (but I am not sure who
implemented this piece).

       Since version 2.4, Linux supports the use of MSG_TRUNC in
       the flags argument of  recv(2)  (and  recvmsg(2)).   This
       flag  causes  the received bytes of data to be discarded,
       rather than passed  back  in  a  caller-supplied  buffer.
       Since  Linux  2.4.4,  MSG_PEEK  also has this effect when
       used in conjunction with MSG_OOB to  receive  out-of-band
       data.

Cheers,

Michael
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html