This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug manual/10996] New: Local socket documentation omissions
- From: "siward at wanadoo dot nl" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 22 Nov 2009 05:43:23 -0000
- Subject: [Bug manual/10996] New: Local socket documentation omissions
- Reply-to: sourceware-bugzilla at sourceware dot org
Hello libc people,
i was using local sockets in a new program (on Debian stable)
and came across some undocumented behaviour
that i think would be good to mention in libc manual.
I have checked latest version of manual,
that i found from GNU site in manuals section, as one-page html.
This appears exactly identical to version i have on my system.
Issues are :
DATATYPE OF FD_SET
Documentation says that it is a bit-array, and that it is overwritten,
but in example in section 'bytestream connection server example'
value of one fd_set is assigned to another fd_set,
using a simple assignment with '='.
So, is fd_set really a pointer
and does select not overwrite contents of set but only overwrite pointer ?
This should be documented, imo.
EOF WITH LOCAL SOCKETS
Documentation mentions that local sockets are 'like a pipe',
so i expected that a read may be broken in multiple pieces
if message is larger than PIPE_BUF,
and that therefore read() should be called in a loop until it returns zero,
and zero returnvalue would indicate end of message.
So i made a function that reads in a loop,
using alloca() to get needed buffer size,
and when read returns 0,
it mallocs correct size and copies to malloced buffer.
In practice i find that calling read() in a loop hangs program,
and that returnvalue 0 is used in example to indicate that
other end of connection was shut down.
It would have been nice if this had been mentioned
in description of local sockets,
since it cost me a few days to understand.
Also i wonder what will happen if a very large message is sent over local
socket ;
write will be done in multiple steps, that is no problem,
but how will reader know there is more message than it read ?
And which size buffer should reader allocate ?
it must be large to cater for very large messages,
so maybe it should be PIPE_BUF bytes ?
On my system PIPE_BUF is 4096 bytes, so that is not very large.
With both these things,
i would have benefitted from more clarification,
which reminds me to be thankfull to you for all the content you already
provide.
Thanks !
Have a nice day !
:-)
Siward de Groot
--
Summary: Local socket documentation omissions
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: manual
AssignedTo: roland at gnu dot org
ReportedBy: siward at wanadoo dot nl
CC: glibc-bugs at sources dot redhat dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=10996
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.