From: "René Scharfe" <l.s.r@web.de>
To: David Turner <dturner@twosigma.com>, git@vger.kernel.org
Subject: Re: [PATCH] xgethostname: handle long hostnames
Date: Fri, 14 Apr 2017 00:32:03 +0200 [thread overview]
Message-ID: <aa10d2cb-c21a-fbfd-9fae-0d0153e4901b@web.de> (raw)
In-Reply-To: <20170413192335.20679-1-dturner@twosigma.com>
Am 13.04.2017 um 21:23 schrieb David Turner:
> If the full hostname doesn't fit in the buffer supplied to
> gethostname, POSIX does not specify whether the buffer will be
> null-terminated, so to be safe, we should do it ourselves. Introduce
> new function, xgethostname, which ensures that there is always a \0
> at the end of the buffer.
>
> Signed-off-by: David Turner <dturner@twosigma.com>
> ---
> diff --git a/wrapper.c b/wrapper.c
> index 0542fc7582..d837417709 100644
> --- a/wrapper.c
> +++ b/wrapper.c
> @@ -655,3 +655,16 @@ void sleep_millisec(int millisec)
> {
> poll(NULL, 0, millisec);
> }
> +
> +int xgethostname(char *buf, size_t len)
> +{
> + /*
> + * If the full hostname doesn't fit in buf, POSIX does not
> + * specify whether the buffer will be null-terminated, so to
> + * be safe, do it ourselves.
> + */
> + int ret = gethostname(buf, len);
> + if (!ret)
> + buf[len - 1] = 0;
> + return ret;
> +}
Silent truncation is not ideal, no matter if it's done by the wrapper or
the original function. It would be better to use a properly sized
buffer.
POSIX requires hostnames to have a maximum length of HOST_NAME_MAX. So
how about just adding an assert to make sure len is big enough? Or
evaluate the condition at compile time with BUILD_ASSERT_OR_ZERO?
Downside: Not all platforms define HOST_NAME_MAX. daemon.c uses 256 as
a fallback. On Windows a buffer size of 256 is documented to suffice
in all cases [1]. The Linux manpage [2] mentions a hostname length
limit of 255 (plus NUL) as well, even though HOST_NAME_MAX is 64 there.
Another possibility: Die (or at least warn) if the buffer doesn't
contain a NUL byte after calling gethostname(). That only works for
platforms that don't NUL-terminate on truncation, though, so silent
truncation would still go unnoticed.
Anyway, the buffer in builtin/gc.c with its 128 bytes seems to be too
short; the others are at least 256 bytes long. Replacing the magic
buffer size number with HOST_NAME_MAX + 1 might be a good idea (after
moving the fallback definition to git-compat-util.h).
René
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms738527(v=vs.85).aspx
[2] http://man7.org/linux/man-pages/man2/gethostname.2.html
prev parent reply other threads:[~2017-04-13 22:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-13 19:23 [PATCH] xgethostname: handle long hostnames David Turner
2017-04-13 21:23 ` Jeff King
2017-04-13 22:05 ` Jonathan Nieder
2017-04-13 22:29 ` David Turner
2017-04-13 22:32 ` René Scharfe [this message]
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=aa10d2cb-c21a-fbfd-9fae-0d0153e4901b@web.de \
--to=l.s.r@web.de \
--cc=dturner@twosigma.com \
--cc=git@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox