Re: What's cooking in git.git (Apr 2017, #02; Sun, 16)

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 18, 2017, 01:56 UTC
Message-ID: <xmqqo9vuh420.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <e6f869b1-09c2-88eb-d79d-b0dc2090a632@web.de>

René Scharfe <l.s.r@web.de> writes:

Show 28 quoted lines

> Am 17.04.2017 um 09:30 schrieb Junio C Hamano:
>> * dt/xgethostname-nul-termination (2017-04-13) 1 commit
>>   - xgethostname: handle long hostnames
>> 
>>   gethostname(2) may not NUL terminate the buffer if hostname does
>>   not fit; unfortunately there is no easy way to see if our buffer
>>   was too small, but at least this will make sure we will not end up
>>   using garbage past the end of the buffer.
>> 
>>   Will merge to 'next'.
>
> [Sorry for repeating, but I didn't see a direct reply.]
>
> If a host name doesn't fit then the buffer is too small.  Let's make it
> big enough, reducing the number of magic constants and avoiding silent
> truncation all at the same time.  Patch for that:
>
> -- >8 --
> Subject: [PATCH] use HOST_NAME_MAX to size buffers for gethostname(2)
>
> POSIX limits the length of host names to HOST_NAME_MAX.  Export the
> fallback definition from daemon.c and use this constant to make all
> buffers used with gethostname(2) big enough for any possible result
> and a terminating NUL.
>
> Inspired-by: David Turner <dturner@twopensource.com> 
> Signed-off-by: Rene Scharfe <l.s.r@web.de>
> ---

Thanks. Let's have this one immediately before David's xgethostname() patch on the same topic branch.

The fact that the length of my_host[] vs locking_host[] being different still remains, though. I do not know if it matters.