Re: Feature Request - CMP

[Tyler Beaver]

If there were an explicit flag, I don't think there would be ambiguity, personally speaking. It would still default to octal of course, but if there were a --base 0x that you had to explicitly add then you would get 0xFF instead of 377. But I also think patching --help and/or man, as well as a preceeding 0.

On Fri Feb 06 2015 at 10:45:17 AM Eric Blake <address@hidden> wrote:

On 02/06/2015 09:23 AM, Pádraig Brady wrote:
> On 06/02/15 15:57, Tyler Beaver wrote:
>> I know this tool is probably note used as much anymore, but perhaps it would be worth adding a flag for overriding the verbose output number system for the values, or at any rate specifying that this output is in octal, and not decimal or hexadecimal.
>
> Currently: offsets are decimal, differing bytes are octal:
>
>   $ cmp -l <(echo 12345678abc) <(echo 12345678bbb)
>                     9 141 142
>                    11 143 142
>
> This works the same on all unix systems.
> What would changing base provide except ambiguity?

The behavior of -l (--verbose) is mandated by POSIX:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cmp.html
> When the -l option is used, the format shall be:
>
> "%d %o %o\n", <byte number>, <differing byte>,
>     <differing byte>

That said, it might be worth patching 'cmp --help' to make it obvious
that differing bytes are in octal values.

Also, POSIX allows us to write this as:

  9 0141 0142
 11 0143 0142

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap05.html
> If both the field width and precision are omitted, the implementation may precede, follow, or precede and follow numeric arguments of types d, i, and u with <blank> characters; arguments of type o (octal) may be preceded with leading zeros.

So we would still be compliant if we tweaked the output to make it more
blatantly obvious that we are outputting octal character values.

--
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org