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

[Junio C Hamano <gitster@pobox.com>]

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

> 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.