Gunnar Ritter <yyyyyyyyyyyyy@xxxxxxxxxxxxxxxxxxxxx> wrote on 01/26/2005
12:22:09 PM:
> Mark Brown <yyyyy@xxxxxxxxxx> wrote:
>
> > The #1 reason why it shouldn't: POSIX as a matter of basic intent does
not
> > specify any particular character set encoding. This basic principle
goes
> > all the way back to the first work on I18N in the specification.
>
> The restriction does not specify an encoding. It merely requires
> consistency between the "char" and "wchar_t" forms of the encoding
> chosen by the implementor. It only becomes a problem for EBCDIC (or
> other possible ASCII-incompatible encodings) if they want to give
> up this consistency and use Unicode for wchar_t.
Right. ISO C allows this, and you are requesting that POSIX
disallow it, thus restricting the encodings allowed by POSIX. This
is specifying encodings, by restriction.
> And we do have a comparable situation here: Conforming code that relies
> on ('a' == L'a') will no longer be conforming without that requirement.
> Even more so as the proposal is not only to make this implementation-
> defined, but to be just silent about it.
OK, we might have something to discuss here. Your claim is strictly
conforming
applications become non-conforming via [XBD Sec 2.1.1 sub 6]
| 2.2.1 Strictly Conforming POSIX Application
| A Strictly Conforming POSIX Application is an application that requires
only the
| facilities described in IEEE Std 1003.1-2001. Such an application:
| ....
| 6. For the C programming language, shall not produce any output
dependent on
| any behavior described in the ISO/IEC 9899: 1999 standard as
unspecified,
| undefined, or implementation-defined, unless the System
Interfaces volume of
| IEEE Std 1003.1-2001 1201 specifies the behavior.
Not *broken* (they will still operate just fine on all ASCII-based
implementations
of POSIX), just not Strictly Conforming. We aren't breaking any
applications or
implementations by allowing this. But I take your point.
My claim is that we will now have Conforming Language bindings (per ISO C)
that
cannot be used with POSIX due to what appear to be mainly correctable
performance
considerations.
[discussion of value of arguments of "proof by popularity" deleted]
Comments from the gallery?
-------------------
Mark Brown/Austin/IBM
yyyyy@xxxxxxxxxx
|