Alle mercoledì 28 marzo 2012, Jelmer Vernooij ha scritto: > On 03/28/2012 02:55 PM, Pino Toscano wrote: > > Package: heimdal > > Version: 1.6~git20120311.dfsg.1-1 > > Severity: important > > Tags: patch > > User: [email protected] > > Usertags: hurd > > > > Hi, > > > > currently[1], heimdal 1.6~git20120311.dfsg.1 does not compiled on > > hurd-i386. > > The problem is a new occurrence of MAXHOSTNAMELEN not covered by > > patch 041_hurd_maxhostnamelen; the "fix" (just like the others in > > that patch) is to use MaxHostNameLen instead, which is always > > defined. Attached there is a new version of patch > > 041_hurd_maxhostnamelen, refreshed and with the additional hunk > > for lib/krb5/principal.c. > > > > [1] > > https://buildd.debian.org/status/fetch.php?pkg=heimdal&arch=hurd-i386 > &ver=1.6%7Egit20120311.dfsg.1-1&stamp=1331734895 This change seems > fine in general, it's consistent with the rest of the patch.
Thanks. > 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 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). -- Pino Toscano
signature.asc
Description: This is a digitally signed message part.
