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.
+
+****************************************************************
Questions? Ask the ACAA Technical Agent