On Tue, 8 Jan 2008, Junio C Hamano wrote:
> Johannes Sixt <j.sixt@xxxxxxxxxxxxx> writes:
>
> > From: Johannes Sixt <johannes.sixt@xxxxxxxxxx>
> >
> > 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 <johannes.sixt@xxxxxxxxxx>
> > ---
> > 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
