CVS difference for ai12s/ai12-0021-1.txt

--- ai12s/ai12-0021-1.txt	2019/01/04 23:09:12	1.7
+++ ai12s/ai12-0021-1.txt	2019/01/09 00:41:27	1.8
@@ -1304,3 +1304,79 @@
 A.8.2(20), A.10.2(5), and A.12.1(33). So those changes were dropped as well.
 
 ****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, December 12, 2018  1:43 AM
+
+What happens when someone successfully opens a file with a 
+Wide_Wide_Wide_Wide_Wide_String (say, with some emojiis) and then calls the 
+Name that returns a String? One hopes that the result is 
+implementation-defined. Do we need to say something about that, or is it OK 
+to leave it unspecified in the Standard because file names are 
+implementation-defined in the first place?
+
+A similar question can be asked about Form parameters.
+
+The reason I ask is that Name is something at this typically implemented in 
+the Ada runtime (the names of the files are generally not retrievable from 
+open file handles - at least not in Windows or (especially) Unix/Linux, so the 
+Ada runtime has to store this information). Storing the information in multiple
+formats seems bizarre at best, storing it in the most general format is going 
+to waste a lot of space, take a full scan to convert to String, etc. I was 
+thinking about possible Janus/Ada implementations of this feature and it isn't 
+that clear what it is required to do.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, December 12, 2018  7:25 AM
+
+I would agree we can leave it implementation defined, though if you use the 
+same package for opening and calling Name, I would hope you get back what you
+put in.  If I were to implement it, I would use a UTF-8 representation for 
+Wide and Wide_Wide, with some kind of BOM to avoid ambiguity with the Latin-1 
+used for normal strings.  
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, January 7, 2019 11:16 PM
+
+I would tend to agree that at least using the same package for both should do 
+something reproducible (the ACATS assumes that for String, of course, and I'd 
+expect the same for tests for the Wide and Wide_Wide versions), and that 
+Wide_Wide_Characters should still be recognizable when using the Wide_Wide Name.
+
+It seems that we should at least mention in the AARM this expectation.
+Perhaps something like:
+
+Existing A.8.2(28.4/5):
+
+The nested package Wide_File_Names provides operations equivalent to the 
+operations of the same name of the outer package except that Wide_String is 
+used instead of String for the name and form of the external file.
+
+New note:
+
+    AARM Implementation Note: The expectation is that if one opens a file with 
+    this package and then requests the name with Name, the result will include 
+    the same wide_characters that were used to open the file (rather than some 
+    encoded form). Since file names are completely implementation-defined, we
+    can't say this normatively. We have no expectations when retrieving the 
+    name of a file opened with this package using the String Name. Similar 
+    considerations apply to the nested package Wide_Wide_File_Names (see 
+    below).
+
+If this is OK, I'll stick this into the AARM note AI (it's one that we never 
+vote on, it just holds mail like this). Or we could put it into a cleanup AI 
+if we want more work. :-)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, January 7, 2019 11:32 PM
+
+Your suggestion for an AARM note sounds fine.  The point is to explain our 
+intent, so an implementor can try to do the right thing.
+
+****************************************************************