From: Carlos Rica <jasampler@gmail.com>
To: git@vger.kernel.org, "Kristian Høgsberg" <krh@redhat.com>,
"Johannes Schindelin" <Johannes.Schindelin@gmx.de>
Subject: Changes in function read_pipe
Date: Mon, 16 Jul 2007 18:13:45 +0200 [thread overview]
Message-ID: <469B9939.5050800@gmail.com> (raw)
Some people talked recently about renaming the function read_pipe
(sha1_file.c) to the better name read_fd.
Here I discuss other possible changes to the current version:
1. It now requires to allocate memory for the buffer before calling it,
you cannot pass it a pointer set to NULL or not initializated at all.
2. The function doesn't terminate the data with NUL, and if you
need that, you must to realloc before adding the '\0', because
the function only returns the size of the data, not the buffer size.
3. When function fails in reading (xread returns < 0), buffer is not
freed.
I'm not sure which of those issues are really important,
so I thought it was better to ask this in the list.
This is the current implementation of the function:
/*
* reads from fd as long as possible into a supplied buffer of size bytes.
* If necessary the buffer's size is increased using realloc()
*
* returns 0 if anything went fine and -1 otherwise
*
* NOTE: both buf and size may change, but even when -1 is returned
* you still have to free() it yourself.
*/
int read_pipe(int fd, char** return_buf, unsigned long* return_size)
{
char* buf = *return_buf;
unsigned long size = *return_size;
ssize_t iret;
unsigned long off = 0;
do {
iret = xread(fd, buf + off, size - off);
if (iret > 0) {
off += iret;
if (off == size) {
size *= 2;
buf = xrealloc(buf, size);
}
}
} while (iret > 0);
*return_buf = buf;
*return_size = off;
if (iret < 0)
return -1;
return 0;
}
Kristian Høgsberg recently sent some changes to the function
to replace the function with another one easier to call, but
with a different behavior:
/*
- * reads from fd as long as possible into a supplied buffer of size bytes.
- * If necessary the buffer's size is increased using realloc()
+ * reads from fd as long as possible and allocates a buffer to hold
+ * the contents. The buffer and size of the contents is returned in
+ * *return_buf and *return_size. In case of failure, the allocated
+ * buffers are freed, otherwise, the buffer must be freed using xfree.
*
* returns 0 if anything went fine and -1 otherwise
- *
- * NOTE: both buf and size may change, but even when -1 is returned
- * you still have to free() it yourself.
*/
-int read_pipe(int fd, char** return_buf, unsigned long* return_size)
+int read_fd(int fd, char** return_buf, unsigned long* return_size)
{
- char* buf = *return_buf;
- unsigned long size = *return_size;
+ unsigned long size = 4096;
+ char* buf = xmalloc(size);
ssize_t iret;
unsigned long off = 0;
@@ -2328,21 +2327,22 @@ int read_pipe(int fd, char** return_buf, unsigned long* return_size)
*return_buf = buf;
*return_size = off;
- if (iret < 0)
+ if (iret < 0) {
+ free(buf);
return -1;
+ }
+
return 0;
}
Any other ideas? read_pipe is really handy to reuse on builtins,
so we need to decide how we should call to it now before starting
to reuse it in many places.
Comments will be appreciated.
next reply other threads:[~2007-07-16 16:14 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-16 16:13 Carlos Rica [this message]
2007-07-16 23:50 ` Changes in function read_pipe Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=469B9939.5050800@gmail.com \
--to=jasampler@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=krh@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.