From bjkae@celsiustech.se Mon Jul 10 02:52:05 1995 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA28211; Mon, 10 Jul 95 02:52:05 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by inmet.camb.inmet.com (4.1/SMI-4.1) id AA27883; Mon, 10 Jul 95 02:52:00 EDT Received: from world.celsiustech.se by sw-eng.falls-church.va.us (8.6.11/) id GAA26092; Mon, 10 Jul 1995 06:52:54 GMT Received: (from bjkae@localhost) by world.celsiustech.se (8.6.12/8.6.10) id IAA07976; Mon, 10 Jul 1995 08:51:56 +0200 Date: Mon, 10 Jul 1995 08:51:56 +0200 (MET DST) From: Bjorn Kallberg X-Sender: bjkae@world To: ada-comment@sw-eng.falls-church.va.us Subject: Can wchar_t be signed (yes!) In-Reply-To: <9506300400.AA27549@dsd.camb.inmet.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII !topic Can wchar_t be signed !reference RM95-B.3(31) !reference AI95-00037/00 !from Bjorn Kallberg <> !discussion In the proposed AI95, it is suggested that Interfaces.C.wchar_t is not a signed integer type, even if the C implementation has a signed representation. A better solution is to change (31) to say that wide_nul : constant wchar_t := implementation-defined. instead of the current wide_nul : constant wchar_t := wchar_t'first; The intent of the Interfaces.C is to give an Ada representation of the C types. With the definition of nul as the wchar_t'first, additional semantics which do not exist in C are added. The following is one example where the added restriction is harmful. There may be others. We have an C implementation were wide_char is signed, and we also have a C header file, defining some character values to positive and negative values. Automatic translation of this header file to Ada will not work. The above problem is of course not a major one, but as there is no argument presented except "not harmful" for the other view, it seems much better stay with the original intent, to mimic the C definition as closely as possible. Also, most other constants in this package are implementation defined /bj|rn From brosgol@dsd.camb.inmet.com Mon Jul 10 12:31:17 1995 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA07634; Mon, 10 Jul 95 12:31:17 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by inmet.camb.inmet.com (4.1/SMI-4.1) id AA02926; Mon, 10 Jul 95 12:31:16 EDT Received: from dsd.camb.inmet.com by sw-eng.falls-church.va.us (8.6.11/) id QAA10820; Mon, 10 Jul 1995 16:32:17 GMT Received: from harp.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA07629; Mon, 10 Jul 95 12:30:44 EDT Date: Mon, 10 Jul 95 12:30:44 EDT From: brosgol@dsd.camb.inmet.com (Ben Brosgol) Message-Id: <9507101630.AA07629@dsd.camb.inmet.com> Received: by harp.camb.inmet.com (4.1/SMI-4.1) id AA27792; Mon, 10 Jul 95 12:30:43 EDT To: ada-comment@sw-eng.falls-church.va.us Cc: brosgol@inmet.com, dewar@cs.nyu.edu Subject: Comments on COBOL Interface !topic Correction to the Valid function in COBOL Interface !reference RM95-B.04(63) !reference RM95-B.04(64) !reference RM95-B.04(65) !from Ben Brosgol 95-07-10 !keywords COBOL Interface <> !discussion The Valid function should return False if Item contains leading space characters, when Format is Unsigned, Leading_Separate, or Trailing_Separate (this was pointed out by R Dewar). The wording should thus be corrected as follows in B.4, with brackets indicating text to be deleted. Para 63: "if Item comprises [zero or more leading space characters followed by] one or more decimal digit characters..." Para 64: "if Item comprises [zero or more leading space characters, followed by] a single occurrence of the plus or minus sign character, and then one or more decimal digit characters..." Para 65: "if Item comprises [zero or more leading space characters followed by] one or more decimal digit characters..." !topic Clarification of result length for conversions in COBOL Interface !reference RM95-B.04(71) !reference RM95-B.04(79) !from Ben Brosgol 95-07-10 !keywords COBOL Interface <> !discussion As pointed out by R Dewar, the descriptions of the functions To_Display and To_Packed in the generic package Decimal_Conversions do not specify the length of the returned value (each is an array); the appropriate interpretation is that in each case the length is given by the corresponding Length function applied to the Format parameter. The following should thus be added, both to paragraphs 71 and 79, immediately after the 1st sentence in each paragraph: "The length of the returned value is Length(Format), and the lower bound is 1." Note that the Length function is overloaded; the Format parameter to To_Display and To_Packed resolves which version to use.