[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Libtirpc-devel] Fwd: Re: proposed patch to rpcbind to provide finer-grained security controls than offered by the -i option

On 12/15/2010 05:09 PM, Samuel Thibault wrote:
> Steve Dickson, le Wed 15 Dec 2010 15:48:38 -0500, a écrit :
>>> Building it with ``make -k'':
>>>     ../../master/src/auth_unix.c:187: error: ‘MAXHOSTNAMELEN’ undeclared (first use in this function)
>> I don't understand what this is complaining about. Obviously
>> MAXHOSTNAMELEN is define (see rpc/types.h) otherwise the non-hurd build
>> would fail.
> MAXHOSTNAMELEN is defined on some OSes, but not on others, as POSIX says
> it's an optional macro (it's not defined when there is no limitation). See
> http://www.gnu.org/software/hurd/hurd/porting/guidelines.html#PATH_MAX_tt_MAX_PATH_tt_MAXPATHL
The link to Neil's xgethostname() (http://ftp.walfield.org/pub/people/neal/xgethostname/)
is broken... So I googled around and found 
I'm assuming that's latest and greatest version. 

>> Also, I've realized adding:
>>     #ifndef MAXHOSTNAMELEN
>>     #define MAXHOSTNAMELEN 64
>>     #endif
>> to auth_unix.c eliminates this "error".
> That's a crude way, but yes it should work.
Looking around in the glibc code I see this in a number of places:

/* As per RFC 1034 and 1035 a host name cannot exceed 255 octets in length.  */

Is this a less crude way of correcting the error?

>> But again those ifdefs are not needed on "normal" builds so what
>> gives?
> They are not needed on OSes which have a hostname lenght limitation, but
> they are needed on OSes which don't.
>>>     ../../master/src/bindresvport.c:189: error: ‘IPV6_PORTRANGE’ undeclared (first use in this function)
>>>     ../../master/src/bindresvport.c:190: error: ‘IPV6_PORTRANGE_LOW’ undeclared (first use in this function)
>> This is true but these defines are in non-Linux code so I guess
>> the hurd builds defines both Linux and non-Linux parts of the code?
> It just means that these are not Linux-only.  But that doesn't mean it's
> standard macros.  And indeed, while some other IPV6_* macros are in
> posix, IPV6_PORTRANGE* are not, and thus aren't standard.
Ok... I'll just locally define them... 



Reply to: