CVS difference for ais/ai-00038.txt

Differences between 1.1 and version 1.2
Log of other versions for file ais/ai-00038.txt

--- ais/ai-00038.txt	1998/09/30 00:17:08	1.1
+++ ais/ai-00038.txt	1999/07/08 17:28:21	1.2
@@ -1,4 +1,4 @@
-!standard B.3      (46)                               96-06-06  AI95-00038/02
+!standard B.3      (46)                               99-07-08  AI95-00038/03
 !class confirmation 95-06-25
 !status WG9 approved 95-06-14
 !status ARG approved 10-0-0 (by letter ballot) 96-06-05
@@ -6,7 +6,7 @@
 !status received 95-06-25
 !subject Mapping between Interfaces.C.char and Standard.Character
 
-!summary 96-05-08
+!summary
 
 The To_C and To_Ada functions in Interfaces.C map between corresponding
 characters, not necessarily between characters with the same internal
@@ -14,7 +14,7 @@
 same enumeration literal, if such exist; otherwise, the correspondence
 is not defined by the language.
 
-!question 95-06-25
+!question
 
 This paragraph states that To_Ada and To_C map between Character and
 char, but does not explain how.  Presumably, Interfaces.C.char
@@ -24,7 +24,7 @@
 To_C('A') yield the C.Interfaces.char value corresponding to EBCDIC 'A',
 or does it yield the character whose EBCDIC code is Character'Pos('A')?
 
-!response 95-06-25
+!response
 
 The intent is that 'A' maps to 'A', even if the two 'A's have a
 different representation.
@@ -39,8 +39,22 @@
        provided that Character'Value does not raise an exception;
        otherwise the result is not defined by the language.
 
-!appendix 96-06-06
+!ACATS test
 
+Create a C-Test to check that the value of strings converted via To_Ada and
+To_C have the same meaning in both Ada and C. Such a test ought to restrict
+the characters used to ones available everywhere - i.e. letters and numbers.
+
+A suggested implementation plan: Create a test with both Ada and C parts
+(like CXB3013). That is have a C routine which checks that a string passed
+to it matches some literal, and returns 0 or 1 to signify success. Pass this
+routine various strings constructed with To_C, and check that the results are
+correct. Have a second C routine which constructs and returns a known string
+(perhaps based on a parameter). On the Ada side, use To_Ada to convert this
+string, then check that it matches the known string literal.
+
+!appendix
+
 !section B.3(46)
 !subject Mapping between Interfaces.C.char and Standard.Character
 !reference RM95-B.3(46)
@@ -123,17 +137,17 @@
 !reference 96-5522.a demery@CCGATE.HAC.COM 96-4-29>>
 !discussion
 
->[Norm] call[s] for a letter ballot on AI-38, which, [he] believe[s], 
+>[Norm] call[s] for a letter ballot on AI-38, which, [he] believe[s],
 >needs more work.
 
 We spent a lot of time on this area in POSIX, and I strongly
 suggest that the ARG take a good look at the character correspondence
 rules in Chapter 8 (and the rationale) of the POSIX/Ada binding.
 (This is very well covered in the POSIX/Ada tutorial we've given several
-times at Tri-Ada, Ada-Europe and Ada-UK.  If you have a copy of the 
-TA tutorial proceedings from 92 or 93, it's in there.)  
+times at Tri-Ada, Ada-Europe and Ada-UK.  If you have a copy of the
+TA tutorial proceedings from 92 or 93, it's in there.)
 
-Jim Moore did most of the work on this (both the standard and the 
+Jim Moore did most of the work on this (both the standard and the
 tutorial :-).
 
                     dave
@@ -153,14 +167,14 @@
   is not defined by the language.
 
 I think we need to be a bit more specific in the "doesn't match" case.  In
-particular, we can: 
-    a.  raise Constraint_Error 
+particular, we can:
+    a.  raise Constraint_Error
     b.  return an implementation-defined value in the target type
     c.  return a language (AI :-) defined value in the target type
     d.  consider this a bounded error
 
 Option 'a' retains the "flavor" of checked conversions, and I tend to prefer
-this approach.  
+this approach.
 
 If users don't want this behavior, then they can implement the other
 behaviors by interpreting the 'pos or even the underlying value bit
@@ -183,13 +197,13 @@
 The effect of making the mappings implementation-dependent is to remove their
 utility for portability.   I do NOT think we want to do this.  Either
 we have to provide some notion of portable/dependable semantics, or we
-give up entirely.  
+give up entirely.
 
 My position is as follows:
     1.  The mapping function is defined so that character literals are
         preserved, i.e. to_c ('a') returns the C encoding of the character
         literal 'a'.  This is defined for all character literals that appear
-        in both the Ada and C implementations.  
+        in both the Ada and C implementations.
 
     2.  Where a literal does not appear in both Ada and C, the options are:
             a.  implementation-defined (Norm's recommendation)
@@ -200,7 +214,7 @@
 I can live with 2a, 2b or 2d, but not 2c.  I believe that 2b is the right
 answer for this operation, since the user can define an implementation-specific
 mapping function (based on 'pos, for instance), and the Ada predefined
-function should "look like" other type conversion functions (which 
+function should "look like" other type conversion functions (which
 generally raise Constraint_Error in similar circumstances.)
 
 

Questions? Ask the ACAA Technical Agent