Trond Myklebust wrote:
> On Fri, 2007-08-31 at 10:30 -0400, Chuck Lever wrote:
>> Trond Myklebust wrote:
>>> On Fri, 2007-08-31 at 10:08 -0400, Chuck Lever wrote:
>>>
>>>>>  
>>>>> +/*
>>>>> + * RFC1833/RFC3530 rpcbind (v3+) well-known netid's.
>>>>> + */
>>>>> +#define	RPCB_NETID_UDP	"\165\144\160"		/* "udp" */
>>>>> +#define	RPCB_NETID_TCP	"\164\143\160"		/* "tcp" */
>>>>> +#define	RPCB_NETID_UDP6	"\165\144\160\066"	/* "udp6" */
>>>>> +#define	RPCB_NETID_TCP6	"\164\143\160\066"	/* "tcp6" */
>>> BTW: Any reason why we are using escaped octal instead of plain ascii
>>> here?
>> Is there a guarantee that these C strings will be US-ASCII on *every* 
>> platform in every locale on which Linux kernels are built?  Z-series, 
>> for example?
>>
>> If yes, then we can use a normal string.

> You might have somebody convert all the strings in the kernel into
> EBCDIC, just for fun, but that will make the strings unreadable on the
> computer running the resulting kernel ('cos Linux uses ASCII) and would
> likely break all sorts of kernel-userspace interfaces besides breaking
> this little snippet in the rpcbind code.

Well, according to Harbison & Steele, the C source and eventual 
execution character set can be different.  I'm not as certain as you are 
of the guarantee that the Linux kernel environment is US-ASCII on every 
platform from compile to execution.  I've actually written C system 
programs in OpenEdition on MVS/390.

However, if you are comfortable using just a plain old C string (and 
maybe keeping documentation of the US-ASCII requirement in a comment), 
have Tom replace the octal strings with C character strings in his patch.