CVS difference for ai05s/ai05-0286-1.txt
--- ai05s/ai05-0286-1.txt 2012/03/13 01:49:19 1.4
+++ ai05s/ai05-0286-1.txt 2012/03/13 23:55:51 1.5
@@ -1,7 +1,15 @@
-!standard 2.1(16/2) 12-02-24 AI05-0286-1/03
-!standard A.16(126/2)
+!standard 2.1(16/2) 12-03-12 AI05-0286-1/04
+!standard 2.1(18)
+!standard A.3.5(0)
+!standard A.4.7(1/2)
+!standard A.4.7(1/2)
+!standard A.4.7(29/2)
+!standard A.4.8(1/2)
+!standard A.4.8(29/2)
+!standard A.4.10(0)
!class Amendment 12-02-10
!status Amendment 2012 12-02-10
+!status ARG Approved 6-0-4 12-02-25
!status work item 12-02-10
!status received 11-10-01
!priority Medium
@@ -16,19 +24,21 @@
Equal_Case_Insensitive and Hash_Case_Insensitive are added for Wide_String and
Wide_Wide_String.
-We recommend that implementations support UTF-8 encoded input and output for
-file and directory operations, exception information, and the command line. But
-we have no advice on how to do this at this time; implementation experience is
-necessary in order to do this without breaking existing code and/or adding many
-rarely used subprograms.
+We considered recommending that implementations support UTF-8 encoded input and
+output for file and directory operations, exception information, and the command
+line. But we were unable to come up with specific advice on how to do this at
+this time; implementation experience is necessary in order to do this without
+breaking existing code and/or adding many rarely used subprograms.
!proposal
+The Swiss National Body submitted a comment summarized below:
+
Full support for Unicode characters is becoming increasingly important. Ada 2005
added support for international identifiers in Ada programs, yet the support for
Unicode is still incomplete in Ada.
-We recommend that Ada adopt some solution so that:
+The Swiss comment recommends that Ada adopt some solution so that:
(1) Compilers are required to support Unicode characters in source form, by
requiring some form of standard source representation (presumably UTF-8);
@@ -42,11 +52,13 @@
(4) Command lines should support Unicode characters
(presuming that the target system allows these).
-[Editor's note: The Swiss comment ends here. See also the discussion section.]
+[Editor's note: This last item derives from consideration of the entire
+Swiss comment, but not directly. See the discussion section for
+an explanation.]
(5) Case insensitive operations should be provided for Wide_String and
-Wide_Wide_String in the normal way (not just for String). This should use simple
-case folding.
+Wide_Wide_String in the normal way (not just for String). These should use
+simple case folding, like identifier equivalence.
!wording
@@ -60,7 +72,7 @@
code point. The character pair Carriage Return/Line Feed (code points 16#0D#
16#0A#) signifies a single end of line (see 2.2); every other occurrence of a
format_effector other than the character whose code point position is 16#09#
-also signifies a single end of line.
+(CHARACTER TABULATION) also signifies a single end of line.
AARM Reason: This is simply requiring that an Ada implementation be able to
directly process the ACATS, which is provided in the described format. Note that
@@ -75,14 +87,15 @@
We allow line endings to be both represented as the pair CR LF (as in Windows
and the ACATS), and as single format_effector characters (usually LF, as in
Linux), in order that files created by standard tools on most operating systems
-will meet the standard format.
+will meet the standard format. We specify how many line endings each represent
+so that compilers use the same line numbering for standard source files.
-This requirement will increase portability by having a format that is accepted
+This requirement increases portability by having a format that is accepted
by all Ada compilers. Note that implementations can support other source
representations, including structured representations like a parse tree.
End AARM Reason.
-Delete Note 2.1(18) and AARM note 2.1(18.a.1/3).
+Delete Note 2.1(18) and AARM note 2.1(18.a/2).
[Editor's note: "code point" is as defined in ISO/IEC 10646; we mention this
fact in AARM 3.5.2(11.p/3) but not normatively. Formally, this is not necessary
@@ -90,28 +103,49 @@
confusing.]
For (2), (3), and (4), no solution is recommended at this time.
+
+For (5):
+
+Modify A.4.7(1/2):
-For (5), modify A.4.7(29/2):
+Facilities for handling strings of Wide_Character elements are found in the
+packages Strings.Wide_Maps, Strings.Wide_Fixed, Strings.Wide_Bounded,
+Strings.Wide_Unbounded, and Strings.Wide_Maps.Wide_Constants, and in the
+{library} functions Strings.Wide_Hash, Strings.Wide_Fixed.Wide_Hash,
+Strings.Wide_Bounded.Wide_Hash, [and] Strings.Wide_Unbounded.Wide_Hash{,
+Strings.Wide_Equal_Case_Insensitive,
+Strings.Wide_Fixed.Wide_Equal_Case_Insensitive,
+Strings.Wide_Bounded.Wide_Equal_Case_Insensitive,
+Strings.Wide_Unbounded.Wide_Equal_Case_Insensitive,
+Strings.Wide_Hash_Case_Insensitive,
+Strings.Wide_Fixed.Wide_Hash_Case_Insensitive,
+Strings.Wide_Bounded.Wide_Hash_Case_Insensitive,
+Strings.Wide_Unbounded.Wide_Hash_Case_Insensitive}.
+They provide the same string-handling operations as the corresponding packages
+and functions for strings of Character elements.
+Modify A.4.7(29/2):
+
"For each of the packages Strings.Fixed, Strings.Bounded, Strings.Unbounded, and
Strings.Maps.Constants, and for {library} functions Strings.Hash,
Strings.Fixed.Hash, Strings.Bounded.Hash, [and] Strings.Unbounded.Hash{,
-Strings.Hash_Case_Insensitive, Strings.Fixed.Hash_Case_Insensitive,
-Strings.Bounded.Hash_Case_Insensitive, Strings.Unbounded.Hash_Case_Insensitive,
Strings.Equal_Case_Insensitive, Strings.Fixed.Equal_Case_Insensitive,
Strings.Bounded.Equal_Case_Insensitive,
-Strings.Unbounded.Equal_Case_Insensitive}, the corresponding wide string package
-{or function} has the same contents except that"
+Strings.Unbounded.Equal_Case_Insensitive,
+Strings.Hash_Case_Insensitive, Strings.Fixed.Hash_Case_Insensitive,
+Strings.Bounded.Hash_Case_Insensitive, Strings.Unbounded.Hash_Case_Insensitive},
+the corresponding wide string package {or function} has the same contents
+except that"
-Same for A.4.8(29/2).
+Same for A.4.8(1/2, 29/2).
Replace A.4.10(3/3):
- Returns True if the strings are the same, that is if they consist of the same
- sequence of characters after applying locale-independent simple case folding,
- as defined by documents referenced in the note in section 1 of ISO/IEC
- 10646:2011. Otherwise, returns False. This function uses the same method as
- is used to determine whether two identifiers are the same.
+ Returns True if the strings consist of the same sequence of characters after
+ applying locale-independent simple case folding, as defined by documents
+ referenced in the note in section 1 of ISO/IEC 10646:2011. Otherwise, returns
+ False. This function uses the same method as is used to determine whether two
+ identifiers are the same.
AARM Note: For String, this is equivalent to converting to lower case and
comparing. Not so for other string types. For Wide_Strings and
@@ -125,6 +159,11 @@
[Editor's note: Yes, I verified that simple case folding and convert to lower
case do the same thing for type String.]
+Add a new note after A.3.5(63/3):
+
+The case insensitive equality comparison routines provided in
+A.4.10, "String Comparison" are also available for wide strings (see A.4.7).
+
!discussion
The implementation requirement for source code is just saying that it is
@@ -212,6 +251,10 @@
reported any customer interest, so this topic is not one that has been on any
recent ARG agenda. Thus we reluctantly adopted no solution for this problem.
+We've opened an Ada 2012 AI - AI12-0021-1 (for changes to be made after the
+completion of Ada 2012) to keep these issues on the radar for the next version
+of Ada.
+
Similar comments apply to Command_Line processing.
For Ada.Exceptions, we considered adding Wide_ and Wide_Wide_ versions of
@@ -227,54 +270,179 @@
2012. We felt that the Exception_Information changes were insufficiently
valuable to do alone, and perhaps a better general solution will be developed
for Ada 2020 (making all of these Wide_ and Wide_Wide_ routines obsolete.
+This issue also has been added to AI12-0021-1 for future work.
---
-The original comment included an extremely misguided suggestion to provide a
-case insensitive comparison routine for file names. But file name comparison is
-not recommended on Windows (where it would be most useful), because the local
-comparison convention applies to file names. That local convention may be
-different on different file systems accessible from the local machine! Windows
-does not provide an API to do such comparisons, and strongly recommend that they
-be avoided. Moreover, any general Ada-provided routine would use the Unicode
-definitions for case comparison, which are locale-independent and thus would
-not exactly match those used by the file system.
-
-Indeed, we considered adding such a routine in AI05-0049-1, and rejected doing
-so for these and other reasons (detailed in that AI). Since nothing has changed
-about the file systems on operating systems (especially of Windows), nothing has
-changed about the conclusions of that AI.
+The original comment included a suggestion to provide a case insensitive
+comparison routine for file names. But file name comparison is not recommended
+on Windows (where it would be most useful), because the local comparison
+convention applies to file names. That local convention may be different on
+different file systems accessible from the local machine! Windows does not
+provide an API to do such comparisons, and Windows programming materials
+strongly recommend that they be avoided. Moreover, the Ada-provided
+case insensitive comparison routine uses the Unicode definitions for case
+comparison, which are locale-independent and thus would not exactly match those
+used by the file system.
+
+Indeed, we considered adding such a comparision routine in AI05-0049-1, and
+rejected doing so for these and other reasons (detailed in that AI). Since
+nothing has changed about the file systems on operating systems (especially of
+Windows) since the consideration of that AI, nothing has changed about the
+conclusions of that AI.
---
In answering the above, we noticed that we had defined Equal_Case_Insensitive
and Hash_Case_Insensitive for String but not Wide_String. We have rectified that
-situation.
+situation. (Still, using that those routines to compare file names is asking for
+trouble.)
!corrigendum 2.1(16/2)
-@dinsa
+@dinsb
In a nonstandard mode, the implementation may support a different character
repertoire; in particular, the set of characters that are considered
@fa<identifier_letter>s can be extended or changed to conform to local
conventions.
@dinst
-@s8<@i<Implementation Advice>>
+@s8<@i<Implementation Requirements>>
-An Ada implementation should accept Ada source code in UTF-8 encoding, with or
-without a BOM (see A.4.11), where line endings are marked by the pair Carriage
-Return/Line Feed (16#0D# 16#0A#) and every other character is represented by its
-code point.
+An Ada implementation shall accept Ada source code in UTF-8 encoding, with or
+without a BOM (see A.4.11), where every character is represented by its
+code point. The character pair CARRIAGE RETURN/LINE FEED (code points 16#0D#
+16#0A#) signifies a single end of line (see 2.2); every other occurrence of a
+@fa<format_effector> other than the character whose code point position is
+16#09# (CHARACTER TABULATION) also signifies a single end of line.
+
+!corrigendum 2.1(18)
+
+@ddel
+@s9<2 The language does not specify the source representation of programs.>
+
+!corrigendum A.3.5(0)
+
+@dinsc
+This is just a placeholder; the real change is found in the conflict file.
+
+!corrigendum A.4.7(1)
+
+@drepl
+Facilities for handling strings of Wide_Character elements are found in the
+packages Strings.Wide_Maps, Strings.Wide_Fixed, Strings.Wide_Bounded,
+Strings.Wide_Unbounded, and Strings.Wide_Maps.Wide_Constants, and in the
+functions Strings.Wide_Hash, Strings.Wide_Fixed.Wide_Hash,
+Strings.Wide_Bounded.Wide_Hash, and Strings.Wide_Unbounded.Wide_Hash.
+They provide the same string-handling operations as the corresponding packages
+and functions for strings of Character elements.
+@dby
+Facilities for handling strings of Wide_Character elements are found in the
+packages Strings.Wide_Maps, Strings.Wide_Fixed, Strings.Wide_Bounded,
+Strings.Wide_Unbounded, and Strings.Wide_Maps.Wide_Constants, and in the
+library functions Strings.Wide_Hash, Strings.Wide_Fixed.Wide_Hash,
+Strings.Wide_Bounded.Wide_Hash, Strings.Wide_Unbounded.Wide_Hash,
+Strings.Wide_Hash_Case_Insensitive,
+Strings.Wide_Fixed.Wide_Hash_Case_Insensitive,
+Strings.Wide_Bounded.Wide_Hash_Case_Insensitive,
+Strings.Wide_Unbounded.Wide_Hash_Case_Insensitive,
+Strings.Wide_Equal_Case_Insensitive,
+Strings.Wide_Fixed.Wide_Equal_Case_Insensitive,
+Strings.Wide_Bounded.Wide_Equal_Case_Insensitive, and
+Strings.Wide_Unbounded.Wide_Equal_Case_Insensitive.
+They provide the same string-handling operations as the corresponding packages
+and functions for strings of Character elements.
+
+
+!corrigendum A.4.7(29)
+
+@drepl
+For each of the packages Strings.Fixed, Strings.Bounded, Strings.Unbounded, and
+Strings.Maps.Constants, and for functions Strings.Hash, Strings.Fixed.Hash,
+Strings.Bounded.Hash, and Strings.Unbounded.Hash, the
+corresponding wide string package has the same contents except that
+@dby
+For each of the packages Strings.Fixed, Strings.Bounded, Strings.Unbounded, and
+Strings.Maps.Constants, and for library functions Strings.Hash, Strings.Fixed.Hash,
+Strings.Bounded.Hash, Strings.Unbounded.Hash,
+Strings.Hash_Case_Insensitive,
+Strings.Fixed.Hash_Case_Insensitive,
+Strings.Bounded.Hash_Case_Insensitive,
+Strings.Unbounded.Hash_Case_Insensitive,
+Strings.Equal_Case_Insensitive,
+Strings.Fixed.Equal_Case_Insensitive,
+Strings.Bounded.Equal_Case_Insensitive, and
+Strings.Unbounded.Equal_Case_Insensitive, the
+corresponding wide string package or function has the same contents except that
+
+
+!corrigendum A.4.8(1/2)
+
+@drepl
+Facilities for handling strings of Wide_Wide_Character elements are found in
+the packages Strings.Wide_Wide_Maps, Strings.Wide_Wide_Fixed,
+Strings.Wide_Wide_Bounded, Strings.Wide_Wide_Unbounded, and
+Strings.Wide_Wide_Maps.Wide_Wide_Constants, and in the functions
+Strings.Wide_Wide_Hash, Strings.Wide_Wide_Fixed.Wide_Wide_Hash,
+Strings.Wide_Wide_Bounded.Wide_Wide_Hash, and
+Strings.Wide_Wide_Unbounded.Wide_Wide_Hash. They
+provide the same string-handling operations as the corresponding packages and
+functions for strings of Character elements.
+@dby
+Facilities for handling strings of Wide_Wide_Character elements are found in
+the packages Strings.Wide_Wide_Maps, Strings.Wide_Wide_Fixed,
+Strings.Wide_Wide_Bounded, Strings.Wide_Wide_Unbounded, and
+Strings.Wide_Wide_Maps.Wide_Wide_Constants, and in the library functions
+Strings.Wide_Wide_Hash, Strings.Wide_Wide_Fixed.Wide_Wide_Hash,
+Strings.Wide_Wide_Bounded.Wide_Wide_Hash,
+Strings.Wide_Wide_Unbounded.Wide_Wide_Hash,
+Strings.Wide_Wide_Hash_Case_Insensitive,
+Strings.Wide_Wide_Fixed.Wide_Wide_Hash_Case_Insensitive,
+Strings.Wide_Wide_Bounded.Wide_Wide_Hash_Case_Insensitive,
+Strings.Wide_Wide_Unbounded.Wide_Wide_Hash_Case_Insensitive,
+Strings.Wide_Wide_Equal_Case_Insensitive,
+Strings.Wide_Wide_Fixed.Wide_Wide_Equal_Case_Insensitive,
+Strings.Wide_Wide_Bounded.Wide_Wide_Equal_Case_Insensitive, and
+Strings.Wide_Wide_Unbounded.Wide_Wide_Equal_Case_Insensitive.
+They provide the same string-handling operations as the corresponding packages
+and functions for strings of Character elements.
+
+!corrigendum A.4.8(29/2)
+
+@drepl
+For each of the packages Strings.Fixed, Strings.Bounded, Strings.Unbounded, and
+Strings.Maps.Constants, and for functions Strings.Hash, Strings.Fixed.Hash,
+Strings.Bounded.Hash, and
+Strings.Unbounded.Hash, the corresponding wide wide string
+package or function has the same contents except that
+@dby
+For each of the packages Strings.Fixed, Strings.Bounded, Strings.Unbounded, and
+Strings.Maps.Constants, and for library functions Strings.Hash, Strings.Fixed.Hash,
+Strings.Bounded.Hash, Strings.Unbounded.Hash,
+Strings.Hash_Case_Insensitive,
+Strings.Fixed.Hash_Case_Insensitive,
+Strings.Bounded.Hash_Case_Insensitive,
+Strings.Unbounded.Hash_Case_Insensitive,
+Strings.Equal_Case_Insensitive,
+Strings.Fixed.Equal_Case_Insensitive,
+Strings.Bounded.Equal_Case_Insensitive, and
+Strings.Unbounded.Equal_Case_Insensitive, the corresponding
+wide wide string package or function has the same contents except that
-*** !corrigendum A.4.7(29/2) TBD
+!corrigendum A.4.10(0)
+@dinsc
+This is just a placeholder; the real change is found in the conflict file.
+
!ACATS Test
-As this is implementation advice, it is not formally testable. There would be
-value to ignoring the ACATS rules in this case and creating C-Tests that UTF-8
-strings work in file I/O and directory operations, but implementations can only
-be failed for incorrect implementations, not non-existent ones.
+The requirement on source representation is trivially met by running the ACATS;
+nothing further can be tested. (Although the ACATS no longer has to allow
+conversion to other formats, so the documentation should be changed slightly.)
+
+ACATS C-Tests should be created for Equal_Case_Insensitive
+and Hash_Case_Insensitive; in particular, the Wide_String version should
+test "usual" case comparisons (Cyrillic, Greek, etc.) and hashes.
!ASIS
@@ -1309,5 +1477,222 @@
to avoid making work to implementers for which they have no customer demand.
(And if everyone agrees with you, then there cannot be much actual work involved
for other implementations.)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, February 25, 2012 6:38 AM
+
+I am a little worried that the description of the source
+representation required seems to imply that you must use
+CR/LF to represent end of line, and that's not always
+sensible on record oriented systems.
+
+You could argue that in practice this case doesn't arise,
+but then you could also argue that in practice, all Ada
+2012 implementations will do the right thing whether or
+not this IA is in place :-)
+
+
+By the way I consider that the Swiss recommendation as it
+stands:
+
+> (1) Compilers are required to support Unicode characters in
+> source form, by
+> requiring some form of standard source representation
+> (presumably UTF-8);
+
+
+is already met by the standard. Ada compilers must provide SOME way to
+represent all Ada source characters. I know that Randy has a strange
+idea that this is not required, but I think he is alone in that regard.
+
+So the Swiss comment does not in fact lead to anything as specific
+as this AI, although I still think it's fine to require UTF-8.
+
+Regarding file names, how about general IA that does
+not mention Unicode (which just confuses things), and
+instead says something like:
+
+Implementations should support all file and directory names
+supported by the underlying file system (and ensure that
+operations on files and directories handle all names
+appropriately). This for instance ensures properly handling
+spaces in Windows file names, as well as unicode stuff, and
+would require some way of dealing with unicode file names
+on windows.
+
+> (3) Exception messages and exception information should support
+> Unicode
+> characters
+
+This is really purely theoretical musing, in practice an exception
+message is a string of 8 bit codes that can be used anyway you like!
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, February 25, 2012 8:42 AM
+
+> I am a little worried that the description of the source
+> representation required seems to imply that you must use
+> CR/LF to represent end of line, and that's not always
+> sensible on record oriented systems.
+>
+> You could argue that in practice this case doesn't arise,
+> but then you could also argue that in practice, all Ada
+> 2012 implementations will do the right thing whether or
+> not this IA is in place :-)
+
+We considered this, but three things:
+
+(1) A tool to import these files (so long as it can be run by users)
+would meet this requirement.
+
+(2) There aren't many such systems in use, it's nasty to avoid real
+requirements on the vast majority of implementations because of rarely
+used ones.
+
+(3) The "impossible or impractical" exception would surely apply if (1)
+is not true.
+
+...
+> Regarding file names, how about general IA that does
+> not mention Unicode (which just confuses things), and
+> instead says something like:
+>
+> Implementations should support all file and directory names
+> supported by the underlying file system (and ensure that
+> operations on files and directories handle all names
+> appropriately). This for instance ensures properly handling
+> spaces in Windows file names, as well as unicode stuff, and
+> would require some way of dealing with unicode file names
+> on windows.
+
+We considered something like this, but it isn't helpful to users if
+every Ada implementation does it differently. And there is no *obvious*
+way to make this work compatibly in the existing packages - else we
+would have adopted such an advice. As such, this seems dubious at best.
+
+>> (3) Exception messages and exception information should support
+>> Unicode characters
+
+> This is really purely theoretical musing, in practice an exception
+> message is a string of 8 bit codes that can be used anyway you like!
+
+Right, and assuming that it is in any particular form is dangerous,
+because interpreting someones binary encoding as UTF-8 could very well
+turn it into hash.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, February 25, 2012 4:40 PM
+
+...
+> We considered this, but three things:
+> (1) A tool to import these files (so long as it can be run by users)
+> would meet this requirement.
+
+What do you mean by "these files". This already assumes that somehow they are in
+an interchange format that is accessible to the operating system in question.
+This gets into the area of specifying not just codesets and character sequences,
+but also transport formats. I guess in practice all systems must be able to read
+unix style files???
+
+> (2) There aren't many such systems in use, it's nasty to avoid real
+> requirements on the vast majority of implementations because of rarely
+> used ones.
+> (3) The "impossible or impractical" exception would surely apply if (1)
+> is not true.
+
+OK, I guess that's right
+
+...
+>> Regarding file names, how about general IA that does
+>> not mention Unicode (which just confuses things), and
+>> instead says something like:
+>>
+>> Implementations should support all file and directory names
+>> supported by the underlying file system (and ensure that
+>> operations on files and directories handle all names
+>> appropriately). This for instance ensures properly handling
+>> spaces in Windows file names, as well as unicode stuff, and
+>> would require some way of dealing with unicode file names
+>> on windows.
+>
+> We considered something like this, but it isn't helpful to users if
+> every Ada implementation does it differently. And there is no *obvious*
+> way to make this work compatibly in the existing packages - else we
+> would have adopted such an advice. As such, this seems dubious at best.
+
+I stronly disagree, it is VERY useful if your implementation has this property,
+EVEN if it is not portable.
+
+a) most users have zero interest in portability (in our experience)
+
+b) even those users who want portability are better off if they have SOME
+ non-portable way of doing things than no way at all!
+
+****************************************************************
+
+From: Bob Duff
+Sent: Saturday, February 25, 2012 5:12 PM
+
+> > We considered something like this, but it isn't helpful to users if
+> > every Ada implementation does it differently. And there is no *obvious*
+> > way to make this work compatibly in the existing packages - else we
+> > would have adopted such an advice. As such, this seems dubious at best.
+>
+> I stronly disagree, it is VERY useful if your implementation has this
+> property, EVEN if it is not portable.
+
+I think Randy meant that it is not useful to have this as Impl Advice in the RM.
+Yes, of course it's very useful if an impl has this property. But the Impl
+Advice isn't about telling impls what would be very useful.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, March 12, 2012 9:00 PM
+
+Some remarks on this AI as I wrote it during the meeting (and as updated during
+the meeting):
+
+(1) A.4.7(1) and A.4.8(1/2) include a full list of the Wide_ routines; these
+ have to be updated for the new routines. Note that the names of these new
+ routines get prefixed by Wide_: "Wide_Equal_Case_Insensitive" and
+ "Wide_Hash_Case_Insensitive", just like the matching Hash routines.
+
+(2) A user note probably should be added to A.3.5 to point readers to A.4.10 if
+ they are looking for string comparison functions. However, I wasn't able to
+ word that note sensibly, because A.4.10 never mentions Wide_String, and
+ trying to include a reference to A.4.7 made it to complicated to make sense
+ (defeating the purpose). Best I came up with was something like:
+
+ 9 Case insensitive wide string comparison routines can be found in A.4.10,
+ "String Comparison" as modified by A.4.7, "Wide_String Handling".
+
+Not sure that's worth it, so I left it out.
+
+I've made the first change in the AI and Standard. Please make any objections
+ASAP, otherwise I'll consider it "editorial" in nature (I can't quite imagine
+any other option). For the second, suggest better wording, tell me to forget it,
+or just say nothing (which is equivalent to telling me to forget it).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, March 13, 2012 9:46 AM
+
+>... 9 Case insensitive wide string comparison routines can be found in
+> A.4.10, "String Comparison" as modified by A.4.7, "Wide_String Handling".
+>
+> Not sure that's worth it, so I left it out.
+
+How about:
+
+ The case insensitive comparison routines provided in A.4.10 are
+ also available for wide strings (see A.4.7).
****************************************************************
Questions? Ask the ACAA Technical Agent