Hi, Alle mercoledì 28 marzo 2012, Jelmer Vernooij ha scritto: > On 03/28/2012 08:39 PM, Pino Toscano wrote: > > Alle mercoledì 28 marzo 2012, Jelmer Vernooij ha scritto: > >> Looking at these patches for the first time, I do wonder if they > >> do the right thing. My understanding is that there is no fixed > >> limit on path and hostnames on GNU/Hurd. Yet MaxHostNameLen and > >> MaxPathNameLen are (fairly arbitrary) constants, meaning that you > >> *do* end up with a limit by using them instead. Wouldn't the > >> proper fix be to use dynamically allocated strings? > > > > Yes, the ideal solution would be dynamically allocate strings, > > either for paths and for hostname strings. > > Note also MAXHOSTNAMELEN is never used within Linux code (it is > > only defined to 64 in asm/param.h), so this non POSIX constant is > > more like an arbitrary limit, even on Linux (maybe it was used in > > the past, but still didn't make much sense for userland). > > As far as I can tell POSIX says that the return value of > gethostname() is limited to HOST_NAME_MAX: > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/gethostname > .html > > Should we be using that rather than MAXHOSTNAMELEN?
OTOH, HOST_NAME_MAX (just like PATH_MAX and other _MAX defines) are optional in POSIX, see http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html and guess what, there's no HOST_NAME_MAX on Hurd (and not on kFreeBSD either). Interestingly enough, while for POSIX gethostname() never errors out, glibc's implementation can return ENAMETOOLONG if the 'len' argument is smaller than the actual host name length. > >> As using MaxPathNameLen and MaxHostNameLen means there are > >> arbitrary limits anyway, is there any particular reason we > >> couldn't just patch configure to #define MAXHOSTNAMELEN and > >> PATH_MAX if they weren't in limits.h? That seems like a simpler > >> solution and would prevent us from chasing new places where these > >> constants are used. > > > > Not sure; as said above, ideally these two constants shouldn't be > > used (or at most not assume they are always defined, and be able > > to work as if they wouldn't exist). > > It seems simpler to just define them in the source package if they > don't exist though, rather than changing all the individual places > where they're used. I'll see if I can update the patch. > > I'm currently also talking to upstream about consistently using > either pair of constants; hopefully we'll be able to remove these > patches from the Debian package at some point. I see, thanks. -- Pino Toscano
signature.asc
Description: This is a digitally signed message part.
