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 <ebl...@redhat.com> 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 > >
