It looks like my understanding of communicating on PF_NETLINK sockets
is not very clear. I might be in the wrong here. Sorry for the noise
and thanks for the feedback.
Happy hacking,
Debarshi
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, i
* Debarshi Ray wrote on Wed, Aug 20, 2008 at 09:40:13PM CEST:
> Oops sorry! This one is hopefully better.
I don't think you want to recv more than BUFSIZ bytes; and then you
shouldn't need to call realloc for every recv. Only when the next recv
answer will not fit in the current buffer size any m
> 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. Now the BUFSIZ doc
Debarshi Ray wrote:
> size_t
> recvbuf (int sockfd, void **buffer, size_t *size)
> {
> size_t block = BUFSIZ;
> size_t count = 0;
> ssize_t nread;
>
> if (*buffer == NULL)
> *size = block;
>
> for (;;)
> {
> *buffer = xrealloc (*buffer, *size);
> nread = recv (sockfd
Oops sorry! This one is hopefully better.
size_t
recvbuf (int sockfd, void **buffer, size_t *size)
{
size_t block = BUFSIZ;
size_t count = 0;
ssize_t nread;
if (*buffer == NULL)
*size = block;
for (;;)
{
*buffer = xrealloc (*buffer, *size);
nread = recv (sockfd, *bu
* Debarshi Ray wrote on Tue, Aug 19, 2008 at 10:57:33PM CEST:
> > FWIW, your current algorithm of adding BUFSIZ to size causes nonlinear
> > amount of work done in realloc, for reading large files. You might
> > want to increase memory by a constant factor or BUFSIZ, whichever is
> > larger (e.g.,
> FWIW, your current algorithm of adding BUFSIZ to size causes nonlinear
> amount of work done in realloc, for reading large files. You might
> want to increase memory by a constant factor or BUFSIZ, whichever is
> larger (e.g., just like read-file does), and thus less often than you
> recv.
So t
Hello Debarshi,
* Debarshi Ray wrote on Tue, Aug 19, 2008 at 05:29:28AM CEST:
> > *buffer = realloc (*buffer, *size);
>
> Oops, I meant to use xrealloc there.
FWIW, your current algorithm of adding BUFSIZ to size causes nonlinear
amount of work done in realloc, for reading large files. You
> How about using the 'read-file' module, passing it a FILE stream created with
> fdopen()?
Yes, I saw that. However there seems to be many instances of using the
low-level system calls directly, especially in Inetutils where reading
from sockets is quite common.
Happy hacking,
Debarshi
> *buffer = realloc (*buffer, *size);
Oops, I meant to use xrealloc there.
Happy hacking,
Debarshi
Debarshi Ray wrote:
> I was wondering whether gnulib has a function to safely read or recv
> from a file desctiptor.
How about using the 'read-file' module, passing it a FILE stream created with
fdopen()?
Bruno
I was wondering whether gnulib has a function to safely read or recv
from a file desctiptor. I could not find one, and have had to hack
them up on numerous occasions. Here is one such version I wrote while
implementing a feature for GNU Inetutils:
size_t
recvbuf (int sockfd, void **buffer, size_t
13 matches
Mail list logo
