All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Turner <David.Turner@twosigma.com>
To: 'Junio C Hamano' <gitster@pobox.com>,
	Jonathan Nieder <jrnieder@gmail.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>,
	"l.s.r@web.de" <l.s.r@web.de>
Subject: RE: [PATCH v3 2/2] xgethostname: handle long hostnames
Date: Wed, 19 Apr 2017 15:50:34 +0000	[thread overview]
Message-ID: <0701e70b52fe4bdd8e04e4c6918aab7a@exmbdft7.ad.twosigma.com> (raw)
In-Reply-To: <xmqq4lxlcdpf.fsf@gitster.mtv.corp.google.com>

> -----Original Message-----
> From: Junio C Hamano [mailto:gitster@pobox.com]
> Sent: Tuesday, April 18, 2017 10:51 PM
> To: Jonathan Nieder <jrnieder@gmail.com>
> Cc: David Turner <David.Turner@twosigma.com>; git@vger.kernel.org;
> l.s.r@web.de
> Subject: Re: [PATCH v3 2/2] xgethostname: handle long hostnames
> 
> Jonathan Nieder <jrnieder@gmail.com> writes:
> 
> > Hi,
> >
> > David Turner wrote:
> >
> >> 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.
> >
> > I think we should detect the error instead of truncating the hostname.
> > That (on top of your patch) would look like the following.
> >
> > Thoughts?
> > Jonathan
> >
> > diff --git i/wrapper.c w/wrapper.c
> > index d837417709..e218bd3bef 100644
> > --- i/wrapper.c
> > +++ w/wrapper.c
> > @@ -660,11 +660,13 @@ 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.
> > +	 * guarantee that an error will be returned. Check for ourselves
> > +	 * to be safe.
> >  	 */
> >  	int ret = gethostname(buf, len);
> > -	if (!ret)
> > -		buf[len - 1] = 0;
> > +	if (!ret && !memchr(buf, 0, len)) {
> > +		errno = ENAMETOOLONG;
> > +		return -1;
> > +	}
> 
> Hmmmm.  "Does not specify if the buffer will be NUL-terminated"
> would mean that it is OK for the platform gethostname() to stuff
> sizeof(buf)-1 first bytes of the hostname in the buffer and then truncate by
> placing '\0' at the end of the buf, and we would not notice truncation with the
> above change on such a platform, no?

My read of the docs is that not only is that OK, but it is also permitted
for the platform to put sizeof(buf) bytes into the buffer and *not* 
put \0 at the end.

So in order to do a dynamic approach, we would have to allocate some
buffer, then run gethostname, then check if the penultimate element 
of the buffer was written to, and if so, allocate a larger buffer.  Yucky,
but possible.


  reply	other threads:[~2017-04-19 15:50 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-18 21:57 [PATCH v3 0/2] gethostbyname fixes David Turner
2017-04-18 21:57 ` [PATCH v3 1/2] use HOST_NAME_MAX to size buffers for gethostname(2) David Turner
2017-04-19  1:28   ` Jonathan Nieder
2017-04-19  2:57     ` Junio C Hamano
2017-04-19 14:03     ` René Scharfe
2017-04-19 17:28     ` René Scharfe
2017-04-19 19:08       ` David Turner
2017-04-19 19:09       ` Torsten Bögershausen
2017-04-19 20:02         ` René Scharfe
2017-04-20 18:37           ` Torsten Bögershausen
2017-04-20 19:28             ` René Scharfe
2017-04-21  4:18               ` Torsten Bögershausen
2017-04-18 21:57 ` [PATCH v3 2/2] xgethostname: handle long hostnames David Turner
2017-04-19  1:35   ` Jonathan Nieder
2017-04-19  2:51     ` Junio C Hamano
2017-04-19 15:50       ` David Turner [this message]
2017-04-19 16:43         ` René Scharfe
2017-04-19  2:48   ` Junio C Hamano

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=0701e70b52fe4bdd8e04e4c6918aab7a@exmbdft7.ad.twosigma.com \
    --to=david.turner@twosigma.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=l.s.r@web.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.