> On Dec. 2, 2014, 5:58 p.m., Dominic Hamon wrote: > > 3rdparty/libprocess/3rdparty/stout/include/stout/net.hpp, line 139 > > <https://reviews.apache.org/r/28589/diff/1/?file=779860#file779860line139> > > > > should we check for ENAMETOOLONG here? it seems a shame to expose this > > to the caller when there's nothing they can do to fix it.
>From man gethostname: " SUSv2 guarantees that "Host names are limited to 255 bytes". POSIX.1-2001 guarantees that "Host names (not including the terminat? ing null byte) are limited to HOST_NAME_MAX bytes". On Linux, HOST_NAME_MAX is defined with the value 64, which has been the limit since Linux 1.0 (earlier kernels imposed a limit of 8 bytes). " Theoretically, 512 would be enough. It's safer to use HOST_NAME_MAX or _POSIX_HOST_NAME (if someone has a custom kernel). I 'll use this ones if I am sure that they are supported also on OS X. What do you think? bits/local_lim.h:#define HOST_NAME_MAX 64 bits/posix1_lim.h:#define _POSIX_HOST_NAME_MAX 255 - Evelina ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28589/#review63550 ----------------------------------------------------------- On Dec. 2, 2014, 2:07 a.m., Evelina Dumitrescu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/28589/ > ----------------------------------------------------------- > > (Updated Dec. 2, 2014, 2:07 a.m.) > > > Review request for mesos, Dominic Hamon and Joris Van Remoortere. > > > Repository: mesos-git > > > Description > ------- > > Created initialization wrappers for sockaddr_in and addrinfo. > > > Diffs > ----- > > 3rdparty/libprocess/3rdparty/stout/include/stout/net.hpp > a992bd9f7caf3abcc2c5e14519ca7e3ac045bb4b > 3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp > ec259cdee876c64f3e562aa77d4d52e964a173ab > > Diff: https://reviews.apache.org/r/28589/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Evelina Dumitrescu > >
