inconsistent long-only option values

[Eric Blake]

Grepping for a common pattern, I'm noticing:

src/chown.c:  DEREFERENCE_OPTION = CHAR_MAX + 1,
src/chroot.c:  GROUPS = UCHAR_MAX + 1,
src/comm.c:   non-character as a pseudo short option, starting with 
CHAR_MAX + 1.  */
src/comm.c:  CHECK_ORDER_OPTION = CHAR_MAX + 1,
src/cp.c:   non-character as a pseudo short option, starting with 
CHAR_MAX + 1.  */
src/cp.c:  ATTRIBUTES_ONLY_OPTION = CHAR_MAX + 1,

On systems where char is signed, this is 128 vs. 256; on systems where 
char is unsigned, this is always 256.

As long as getopt_long() is not called with a short-option string that 
contains \x80 as an available short option, then the use of CHAR_MAX + 1 
will not occur due to someone typing:

chown -$'\x80'

so I guess we're safe regardless of whether char is signed; but it would 
also be nice if we could be consistent within the code base, and either 
always use CHAR_MAX+1, or always use UCHAR_MAX+1, when starting the list 
of long-only option convenience values.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org