Re: [hackers] od: added options -b and -d; bug fix affecting size C

From: FRIGN <>
Date: Fri, 2 Oct 2015 09:44:37 +0200

On Fri, 2 Oct 2015 03:28:34 -0400
Greg Reagle <> wrote:

Hey Greg,

> I am not inclined to join in the IRC because of the large time difference. It
> is 3:30 AM here and I am awake only because I have insomnia and I'll be back in
> bed soon. How about discussing it in Or you can discuss it
> without me on IRC, in which case let me know the result of your discussion.

that's fine! :)

> If you'll forgive my ignorance, I am learning about od by reading the man page
> from section 1posix. How do I learn about which features are XSI extensions?
> Thanks.

Use the OpenGroup-specs. od(1) for instance can be found here[0]. Make sure it
specifies "IEEE Std 1003.1, 2013 Edition" at the top, so you know it's the
2013 corrigendum of POSIX 2013.
XSI-extensions are then easily to see, being marked with "[XSI]".

Now concerning the flags, -b and -c are on the one hand easy to implement.
On the other hand though, this just shows how superfluous these are.
Why do we have "-b" when it's equivalent to "-t o1"?
Why do we have "-d" when it's equivalent to "-t u2"?
And what about the other XSI-extensions? Why don't we include them?
"-c" requires you to handle stuff with LC_CTYPE, which is a huge brainfuck
as well.

We don't handle XSI because we're too lazy, but because every time I read
a POSIX spec and see [XSI], I read [BLOAT].

If you go on implementing XSI-extensions, all other [XSI]-extensions on
the page become mandatory for the program to be POSIX-compliant.
This includes also implementing the -o, -s, -x flags and sections like:

"Multiple types can be specified by using multiple -bcdostx options.
Output lines are written for each type specified in the order in which
the types are specified."

The offset operand specifies the offset in the file where dumping is to
commence. This operand is normally interpreted as octal bytes. If '.' is
appended, the offset shall be interpreted in decimal. If 'b' is appended,
the offset shall be interpreted in units of 512 bytes."

Determine the location of message catalogs for the processing of LC_MESSAGES."

Due to the fucked up syntax of the offset-operand, beware to also check out
APPLICATION USAGE in the informative section:
"XSI-conformant applications are warned not to use filenames starting with
'+' or a first operand starting with a numeric character so that the old
functionality can be maintained by implementations, unless they specify one
of the -A, -j, or -N options. To guarantee that one of these filenames is
always interpreted as a filename, an application could always specify the
address base format with the -A option."

Do you really want that? Let's not touch the forbidden fruit.




Received on Fri Oct 02 2015 - 09:44:37 CEST

This archive was generated by hypermail 2.3.0 : Fri Oct 02 2015 - 09:48:11 CEST