[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFE] function to read a file descriptor

From: Bruno Haible
Subject: Re: [RFE] function to read a file descriptor
Date: Thu, 21 Aug 2008 11:59:34 +0200
User-agent: KMail/1.5.4

Debarshi Ray wrote:
> > What's the use-case of this function? You said that you want to "safely"
> > read from sockfd, but can you explain what you mean by that?
> I am actually reading from a PF_NETLINK socket and want the entire
> data, which can be spread over multiple consecutive messages, in a
> buffer.

I see...

> Now the BUFSIZ documentation says its "value is guaranteed to
> be at least `256'".

It is at least 512 everywhere in practice:
   512 on mingw
  1024 on MacOS X, FreeBSD, OpenBSD, NetBSD, HP-UX, Solaris, Interix, QNX, 
  4096 on AIX, IRIX
  8192 on glibc, OSF/1

> Using read-file might not always be possbile since we would lose the
> 'flags' argument of 'recv'.

But so far your function uses a flags argument of 0. Would any of the flag
values MSG_OOB, MSG_PEEK, MSG_WAITALL make sense here?

> there are instances where having the entire data in a buffer
> makes it easier to parse it. eg., the routing table example.

Sure. But your function does not produce the entire data: it does not read
until EOF. It reads only as far as is available. When more packets become
available, they will be returned through another recvbuf invocation, thus
they will have to be parsed separately. In particular, the parser cannot
assume that it has the entire data, otherwise it has timing related bugs.

This holds for TCP sockets. NETLINK sockets may well be different; I have no
experience with them.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]