наб wrote, on 05 Jun 2023:
>
> Issue 8 Draft 3, XCU, od, OPTIONS says:
> 108112 −j skip Jump over skip bytes from the beginning of the input. The od
> utility shall read or
> 108113 seek past the first skip bytes in the concatenated input
> files. If the combined input is
>
> EXTENDED DESCRIPTION:
> 108266 Unless −A n is specified, the first output line produced for each
> input block shall be preceded by
> 108267 the input offset, cumulative across input files, of the next byte to
> be written. The format of the
>
> EXAMPLES:
> 108317 The command:
> 108318 od -A d -t f -t o4 -t x4 -N 24 -j 0x15
> 108319 on a system with 64-bit doubles (for example, IEEE Std 754-1985
> double precision floating-point
> 108320 format) would skip 21 bytes of input data and then write 24 bytes in
> approximately the
> 108321 following format:
> 108322 0000000 1.00000000000000e+00 1.57350000000000e+01
> 108323 07774000000 00000000000 10013674121 35341217270
> 108324 3ff00000 00000000 402f3851 eb851eb8
> 108325 0000016 1.40668230000000e+02
> 108326 10030312542 04370303230
> 108327 40619562 23e18698
> 108328 0000024
>
> This is obviously wrong ‒
> the addresses should be 0000021 0000037 0000045 ‒
> since (a) naturally, seeking and reading changes the input offset,
> and (b) this is how all historical implementations do it!
>
> SysVr4 od, 4.3BSD od, 4.4BSD old/od all agree with the description here:
> $ ./od.4.3 - +2
> abcd
> 0000002 062143 000012
> 0000005
> $ ./od.4.4.old - +2
> abcd
> 0000002 062143 000012
> 0000005
> $ ../od.sysvr4 - +2
> abcd
> 0000002 061141 062143 000012
> 0000007
> $ echo abcd > ../abcd
> $ ../od.sysvr4 -b ../abcd +2
> 0000002 062143 000012
> 0000005
These all show the behaviour of a +2 operand, not a -j option. The
description of this operand is completely different from the
description of -j:
The offset operand specifies the offset in the file where dumping
is to commence.
The fact that the descriptions are different strongly implies that the
intention is that they behave differently. Otherwise, the offset
operand would have been described by reference to -j (and would likely
have been made obsolescent).
The paragraph you quote about "the input offset" can be interpreted
either way. It is not clear whether input that was "jumped over" should
be included in the reported offset. The only clues as to the intention
for -j are the example, and (together with known historical behaviour of
the offset operand) the fact that the descriptions are different.
> as do coreutils, FreeBSD, and NetBSD (all with -j, natch).
>
> The illumos gate is the only system I've looked at that /does/ actually
> produce 0 as the first address, saying
> /*
> * od - octal dump. Not really just octal anymore; read the POSIX
> * specification for it -- its more complex than you think!
> *
> * NB: We followed the POSIX semantics fairly strictly, where the
> * legacy code's behavior was in conflict. In many cases the legacy
> * Solaris code was so completely broken as to be completely unusable.
> * (For example, the long double support was broken beyond
> * imagination!) Note that GNU coreutils violates POSIX in a few
> * interesting ways, such as changing the numbering of the addresses
> * when skipping. (Address starts should always be at 0, according to
> * the sample output in the Open Group man page.)
> */
> in its fresh od implementation in
>
> https://github.com/illumos/illumos-gate/commit/01335b0d1c4e0c0f16325a830b24ea2a4076fd38
Solaris 11 and HP-UX 11 also produce 0 as the first address with -j 2,
but 2 as the first address with a +2 operand.
Looking at the Illumos code via your link, I think it has this
difference as well, because it has this line:
offset += skip;
(line 773 in the diff listing at your link) which is executed for the
offset operand, but there is no equivalent change to the offset variable
for -j.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
