Thread (3 messages) flat view 3 messages, 3 authors, 2016-06-15

Re: [PATCH 1/2] sideband.c: Use xmalloc() instead of variable-sized arrays.

From: Nicolas Pitre <hidden>
Date: 2016-06-15 22:44:03

On Tue, 8 Jan 2008, Junio C Hamano wrote:
Johannes Sixt [off-list ref] writes:
quoted
From: Johannes Sixt <redacted>

How come we got along with this not very portable construct for so long?
Probably because the array sizes were computed from the results of
strlen() of string constants. Anyway, a follow-up patch will make the
lengths really non-constant.

Signed-off-by: Johannes Sixt <redacted>
---
 sideband.c |   14 ++++++++++++--
 1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/sideband.c b/sideband.c
index 756bbc2..513d7b3 100644
--- a/sideband.c
+++ b/sideband.c
@@ -19,7 +19,10 @@ int recv_sideband(const char *me, int in_stream, int out, int err)
 {
 	unsigned pf = strlen(PREFIX);
 	unsigned sf = strlen(SUFFIX);
-	char buf[pf + LARGE_PACKET_MAX + sf + 1];
+	char *buf, *save;
+
+	save = xmalloc(sf);
+	buf = xmalloc(pf + LARGE_PACKET_MAX + sf + 1);
I have to wonder if the malloc() overhead is small enough
compared to the network bandwidth to make a two malloc-free
pairs per packet a non-issue...
Eeek.  Overhead might be insignificant, but it still doesn't feel right.

What about using alloca() instead?  This is not like if we are doing 
funky things with the allocated memory anyway.


Nicolas
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help