[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#186140: Bug#206210: diff: does not comply with LSB 1.3 (fwd)



On Wed, Sep 03, 2003 at 05:37:24PM +0200, Stefan Gybas wrote:
Michael Stone wrote:

*I don't care.* Tell me what part of the standard is at issue. As I

LSB 1.3 has a list of related standards at http://www.linuxbase.org/spec/refspecs/LSB_1.3.0/gLSB/gLSB/rstandards.html

Yes, I looked at that. Curiously, my copy says:
"The specifications listed below are referenced in whole or in part by
the Linux Standard Base. When a specification is referenced in a way
that imposes a requirement (for example, "foo must behave as specified
in the XyzzySpec"), then the relevant requirements of that specification
apply as if they were part of the LSB itself. However, if the LSB refers
to a specification without imposing a requirement, then it is merely a
reference and does not add additional requirements."

So I continue to request some additional reference showing me what part
of the LSB is at issue.
already said, the goal is LSB compliance, not test suite compliance.

LSB compliance is certified by running the test suite. So if Debian passes the test suite it is LSB compliant. If one or more tests fail, it is not.

Again, I'm interested in the standard. I can't/won't write to a test
suite.
C Language Wide-Character Codes

In the shell, the standard utilities are written so that the encodings of characters are described by the locale's LC_CTYPE definition [...] and there is no differentiation between characters consisting of single octets (8-bit bytes) or multiple bytes. [...]

I'm familiar with SUS3. What you haven't shown yet is a requirement that
the utilities *must* support a multibyte encoding. The section that
you're quoting from does say "In locales other than the POSIX locale, a
character may have a state-dependent encoding." and "IEEE Std
1003.1-2001 does not require that multiple character sets or codesets be
supported." and "If the implementation supports a character encoding of
this type, all of the standard utilities shall support it." IOW, SUS3
isn't itself mandating that you support multibyte characters, it's only
saying that if you do so you must do it in a specific fashion.
This is why I want specific references in the bug report. I shouldn't
have to spend time looking around trying to determine whether your
assertion is correct. I will accept the possibility that I have missed
something in my reading of the standards, they are pretty lengthy. But I
would appreciate an incontrovertible reference rather than an assertion
that my reading is incorrect.

I suspect that any LSB references will turn out the same way, that they
won't mandate multibyte but will say that it needs to work a certain way
if supported. In that case the issue isn't LSB compliance, it's whether
we want to support UTF8 in every program for sarge. That's not, AFAIK,
listed as a release goal at this time. (And I think we're so far away
from such a goal that it can't practically be accomplished without
delaying sarge.)

Mike Stone



Reply to: