Use of the information contained in this unapproved document is at your own risk.

Last update: 20 April,2001

								1003.2-92  #95

 _____________________________________________________________________________

	Interpretation Number:	XXXX
	Topic:			od file operand
	Relevant Sections:	4.45.4


Interpretation Request: (Defect Report)
-----------------------
	Date: Fri, 24 Feb 95 00:52:07 GMT

Dear Standards Board,
	I would like to request a formal interpretation on the following
issue concerning the od utility in POSIX.2.

Standard:		IEEE Std 1003.2-1992
Topic:                  od file operand
Relevant Sections:      4.45.4

	In section 4.45.4 of the description of the od utility's file
	operand (P371, L7342-7346), it says:
	"file	A pathname of a file to be read.  If no file operands are
		specified, the standard input shall be used.  The results
		are unspecified it the first character of file is a plus
		sign (+) or the first character of the first file operand
		is numeric, unless at least one of the -A, -j, -N, or -t
		options is specified."

	Although the rationale doesn't say this, it seems obvious that the
	intent of the last sentence in this description was to allow
	implementations to provide an obsolescent synopsis form,
	corresponding to historic practice, along the lines of:
		od [-bcCDdFfOoSsvXx] [filename] [[+]offset[.][b]]
	Unfortunately, one common command form:
		od -c file 10.
	is not allowed because the offset operand is identified by a
	numeric as the first character of the "second" file operand.
	Although the wording in the standard would allow the command:
		od -c 10.
	to treat 10 as a decimal offset (rather than as a filename),
	historic practice (in both System V and BSD implementations)
	required this to be specified as:
		od -c +10.

	To allow implementations to actually provide the historic forms
	as extensions, the phrase "first character of the first file
	operand" on P371, L7344-7345 should have been "first character
	of the second file operand".

	Was this wording intended to prevent implementations from supporting
	historic behavior, or was this an editorial mistake?



Interpretation response:
-------------------------
The standard states the behavior for the file operand of the od cmd and 
conforming implementations must conform to this.  However, concerns have 
been raised about this which are being referred to the sponsor.


Rationale:
None

Forwarded to Interpretations group: 26 Feb 95
Proposed resolution circulated: May 16th
Comments due: June 15th
Finalised: June 16th 1995