There are several misconceptions in the comments attached to this bug report. Please find comments in-line below...
Cheers, Don Cragun On Nov 25 2009, <User 1-5Q-1267> wrote: > Date: Wed, 25 Nov 2009 13:42:18 -0700 (MST) > To: undisclosed-recipients:; > Subject: [ksh93-integration-discuss] CR 6904780 Updated, P2 > utility/file /usr/bin/chksum changed output in snv_128 > > *Synopsis*: /usr/bin/chksum changed output in snv_128 > > CR 6904780 changed on Nov 25 2009 by <User 1-5Q-1267> > > === Field ============ === New Value ============= === Old Value ============= > > Public Comments New Note > Work Around New Note > ====================== =========================== =========================== > > > *Change Request ID*: 6904780 > > *Synopsis*: /usr/bin/chksum changed output in snv_128 > > Product: solaris > Category: utility > Subcategory: file > Type: Defect > Subtype: > Status: 1-Dispatched > Substatus: > Priority: 2-High > Introduced In Release: > Introduced In Build: > Responsible Engineer: > Keywords: ksh93 > > === *Description* ============================================================ > ... ... ... > === *Public Comments* ======================================================== > Comments from Roland Mainz: > > 1. It looks the AST implementation (AST=="Advanched Software > Technology") is doing a path normalisation here which is AFAIK legal > from a standards point of view... but I ask Don Cragun (POSIX/SUS guru) > about this My reading of the standard is that the standard is not clear on this issue. The standard does not specify how a "file" operand is to be transformed into a <pathname> in the output file format specification in the STDOUT section of the description of cksum. My personal belief is that the intent is that the <pathname> specified in the STDOUT section should match the "file" operand that is being processed (without normalization). There could easily be an exception to this in the case where a "file" operand is "-". If you believe this is important, you need to file an interpretation request for this issue. > > > 2. Question is whether this hurts or not... I am not sure. We discuss > this in the next project meeting this Friday. > > > 3. Quick fix for this bug __may__ be... > -- snip -- > --- a/usr/src/lib/libcmd/common/cksum.c Mon Nov 23 22:09:40 2009 +0100 > +++ b/usr/src/lib/libcmd/common/cksum.c Wed Nov 25 20:45:12 2009 +0100 > @@ -454,7 +454,7 @@ > cmdinit(argc, argv, context, ERROR_CATALOG, ERROR_NOTIFY); > memset(&state, 0, sizeof(state)); > setlocale(LC_ALL, ""); > - flags = fts_flags() | FTS_TOP | FTS_NOPOSTORDER | > FTS_NOSEEDOTDIR; > + flags = fts_flags() | FTS_TOP | FTS_NOPOSTORDER ; > state.flags = SUM_SIZE; > state.warn = 1; > logical = 1; > -- snip -- > ... but this has to be checked twice or three times since my stomach > feeling tells me something is wrong... > > > 4. Just for the log to catch this discussion before it pops-up again: > There was a POSIX bug in the old Solaris implementation of > /usr/bin/cksum which we fixed. Technically you're hitting two issues > here: > 1. /usr/bin/cksum (and the ksh93 builtin version of "cksum") now use > <space> instead <tab> to fully conform to POSIX. That issue was clearly > defined in > http://arc.opensolaris.org/caselog/PSARC/2009/249/20090420_roland.mainz.2 The output format using <tab> instead of <space> fully conformed to the POSIX, SUS, and SVID3 requirements. Changing the <tab> to a <space> will also fully conform to the POSIX, SUS, and SVID3 requirements. The specification of the output format in the STDOUT section of the cksum description in the standard uses file format notation; not a printf() format specification. Using file format notation, " " must be replaced by one or more <space> and <tab> characters in the output. Using file format notation, a single uppercase Greek delta character would have been used in the output format to indicate that a single space had to be output instead of one or more <space> and <tab> characters. > -- snip -- > Note that the implementation will take the specified output format > string "%u %d %s\n" <checksum>, <# of octets>, <path name> now > literally, previously implementation used a <tab> instead of > <space> between %u and %d (the POSIX standard allows both <tab> > and <space>, however GNU and BSD implementations use <space> and > no other implementation except Solaris was found which uses > <tab>). > -- snip -- > The issue went unnoticed since the POSIX test suite had a bug (and > technically has a "loophole" which - in theory - would allow the use of > <tab> (but noone actually used this except Solaris (and even that > "loophole" was closed for the following POSIX revision, leaving no > choice for us))) but now this is being tested and the old implemetation > will fail. There is no loophole and there was no bug in the test suite. The only change to the description of cksum in the latest revision of the standard was in the wording specifying whether "-" is allowed to be interpreted as a synonym for standard input when used as a file operand. > > And AFAIK this is not a backwards-compatibity issue since /usr/bin/cksum > was added to match POSIX/SUS certification requirements and has to match > the standard. I discussed that with John Beck and AFAIK C team, too... > and it was ruled that this is a bug and should be fixed (and > backwards-compatiblity does not matter in this case). As stated above, the standard allows any combination of one or more <space> and <tab> characters. The POSIX standard requirements are met by the old and by the new behavior. PSARC case 2009/249/20090420 documented this change in behavior and correctly noted in the discussion that either output was acceptable according to the standard. > > *** (#1 of 1): 2009-11-25 20:36:19 GMT+00:00 <User 1-5Q-1267> > > > === *Workaround* ============================================================= > Workaround provided by Roland Mainz: > > Please use the "cksum" option "-P" to force a "physical view" of the > path: > -- snip -- > $ /usr/bin/cksum -P /usr/bin/sparcv9/../ls > > 375514533 42212 /usr/bin/sparcv9/../ls > -- snip -- > > We're currently investigating whether the current behaviour is a bug or > standard-conformant (backwards-compatibility only plays a minor role > since "cksum" was invented by the POSIX/SUS people themselves as > _portable_ and _interoperable_ cross-platform hash sum facility and > interoperablity matters more in this case). It is true that cksum was a committee invention, but that was over 17 years ago. Interoperability is the major concern, but after 17 years backwards-compatibility shouldn't be dismissed. (Clearly, any portable applications depending on cksum output will be happy with any number of <space> and <tab> characters between the checksum and the number of octet fields in the output. Therefore, I think the <space> versus <tab> is a non-issue.) Matching the <pathname> output field to a file operand is likely to be much more significant to portable applications. > > *** (#1 of 1): 2009-11-25 20:36:19 GMT+00:00 <User 1-5Q-1267> > ... ... ...
