[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fix xgethostname on OSX [patch]
Mark D. Baushke
Re: fix xgethostname on OSX [patch]
Sun, 20 Feb 2005 07:11:43 -0800
-----BEGIN PGP SIGNED MESSAGE-----
A few points...
1) Please do not use MIME formats in message to
the address@hidden list.
2) It seems that the patch you sent was stripped
by the list software on gnu.org (normally it
throws away attachments of any kind).
3) The lib/xgethostname.c file is maintained in
the GNULIB project. The appropriate place to
report bugs is address@hidden a web page
http://www.gnu.org/software/gnulib/ has the
guidelines for this project.
I am adding address@hidden to this message so
that they see a description of your problem. They
may wish to consider an MacOSX change even without
the patch your message to address@hidden was
Neil Conway <address@hidden> writes:
> The attached one-liner fixes a bug in xgethostname on OSX. It appears
> that gethostname() on OSX will return ENOMEM via errno if the buffer
> that was passed is not sufficiently large to hold the hostname (although
> this isn't documented in the gethostname(3) OSX manpage). The
> implementation of xgethostname only expects ENAMETOOLONG or EINVAL to be
> returned in this case, so xgethostname bails out and returns NULL. Since
> CVS doesn't check the return value of xgethostname() (!), this can
> result in various badness later on (e.g. invoking strlen() on a NULL
> pointer, which was how I ran into this -- the hostname on my system
> happens to be > the initial xgethostname() buffer size).
> The attached patch (against cvs 1.12.11) improves xgethostname() to
> check for ENOMEM as well as ENAMETOOLONG and EINVAL. I grant permission
> to distribute this patch under the terms of the GNU Public License.
> Please apply.
> BTW, I think there is still room for improvement:
> (a) this behavior is not well-standardized. POSIX claims the hostname
> will be truncated if it is larger than the passed-in buffer length (and
> it is undefined whether the return value will be NUL terminated), but
> AFAICS most systems return an error in this case. It seems glibc < 2.1
> will return EINVAL, glibc >= 2.1 and FreeBSD will return ENAMETOOLONG,
> and other systems may well return other errors. It is unnecessary to
> rely on this behavior, anyway: why not just make the buffer size
> HOST_NAME_MAX or MAXHOSTNAMELEN (etc.) to begin with? It seems silly to
> go through this kind of trouble to avoid the allocation of a few hundred
> bytes of memory.
I will leave that for the GNULIB maintainers to consider.
For now, you could add something like
#define INITIAL_HOSTNAME_LENGTH 256
to the generated config.h file so that you didn't
have to modify any of the canonical sources...
> (b) not checking the return value of xgethostname() is fragile.
Yes, we should fix that problem in the CVS sources.
Would it make sense to fallback to "localhost" as the hostname if
xgethostname () returns NULL (in addition to printing an error)?
RCS file: /cvs/ccvs/src/main.c,v
retrieving revision 1.237
diff -u -p -u -p -r1.237 main.c
- --- main.c 1 Feb 2005 22:20:06 -0000 1.237
+++ main.c 20 Feb 2005 15:00:07 -0000
@@ -810,7 +810,14 @@ cause intermittent sandbox corruption.")
/* make sure we clean up on error */
- - hostname = xgethostname();
+ hostname = xgethostname ();
+ if (hostname == NULL)
+ error (0, errno,
+ "xgethostname () returned NULL, using \"localhost\"");
+ hostname = xstrdup ("localhost");
/* Keep track of this separately since the client can change the
or do folks have a better suggestion?
> 2005-02-21 Neil Conway <address@hidden>
> * lib/xgethostname.c: Check for ENOMEM, which is returned by
> OSX/Darwin if the specified buffer is not large enough for the
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
-----END PGP SIGNATURE-----