mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Clemmer <>
Subject Review Request 55544: Windows: Set `MAXHOSTNAMELEN` to an appropriate value.
Date Sun, 15 Jan 2017 09:12:38 GMT

This is an automatically generated e-mail. To reply, visit:

Review request for mesos, Andrew Schwartzmeyer, Daniel Pravat, and Joseph Wu.

Bugs: MESOS-3398

Repository: mesos


The POSIX standard defines a function `getnameinfo`, but does not
specify a maximum length that a hostname can have. To simplify the logic
of choosing a reasonable buffer size to hold the hostname, most
implementations of this specification expose an additional symbol (e.g.,
NI_MAXHOST) that represents the maximum length a hostname can have.

Our code uses `MAXHOSTNAMELEN`, and so on platforms where this symbol is
not implemented (such as Windows), it is necessary to define it.

Currently, `stout/windows.hpp` defines this to be `64`. This value was
chosen because other popular codebases seemed to use this value. But, as
MESOS-3398 explains, we were never sure that this was correct.

Now we have compelling evidence that it isn't: the Windows documentation
for `getnameinfo` clearly states that the maximum length of a hostname
must is captured as `NI_MAXHOST`, and in all recent versions of the
standard libraries, the value of this symbol is 1025.

Hence, for machines with a hostname longer than 64 bytes, almost all the
tests will abort mysteriously, with a cryptic error that claims that the
"data area passed to a system call is too small", which essentially
means that this particular buffer is too small to hold the hostname.

This commit will cause this value to be correctly set on Windows.


  3rdparty/stout/include/stout/windows.hpp d89c70902cf60544441608c2cb290b0727cbb45c 




Alex Clemmer

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message