From rz48@rz.uni-karlsruhe.de  Mon Jun 16 21:36:58 1997
Received: from nz11.rz.uni-karlsruhe.de (nz11.rz.uni-karlsruhe.de [129.13.64.7]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id VAA11521 for <SC22WG5@dkuug.dk>; Mon, 16 Jun 1997 21:36:57 +0200
Message-Id: <199706161936.VAA11521@dkuug.dk>
Received: from ry73.rz.uni-karlsruhe.de by nz11.rz.uni-karlsruhe.de with SMTP (PP); Mon, 16 Jun 1997 21:36:01 +0200
Received: by ry73.rz.uni-karlsruhe.de
	(1.38.193.4/16.2) id AA28609; Mon, 16 Jun 1997 21:35:59 +0200
Subject: C enum support
To: SC22WG5@dkuug.dk
Date: Mon, 16 Jun 1997 21:35:59 +0200 (CES)
From: hennecke@rz.uni-karlsruhe.de (Michael Hennecke)
Reply-To: hennecke@rz.uni-karlsruhe.de (Michael Hennecke)
X-Mailer: ELM [version 2.4ME+ PL31 (25)]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2688      

From J3/97-187r1 (U.S. Comments on Interoperability PDTR Ballot)
>
>   3.3.3
>     Perhaps we could provide partial support for enum types
>     with integer kind parameters named C_SCHAR_ENUM (for
>     enums whose value is within the signed char range),
>     C_SHORT_ENUM (for those whose value is within the short
>     int range), etc.  This may help in almost all cases,
>     but does not necessarily solve the problem, since the
>     C processor may not use straightforward rules in
>     determining the representation for the enum type.
>     Or perhaps a SELECTED_ENUM_KIND(LOW_ENUM, HIGH_ENUM).

I do not see any advantage in defining extra kind parameters like
C_SCHAR_ENUM. If an enum's type is a signed integer, that integer kind 
can be used directly: I expect that C_*_ENUM==C_* for * in SCHAR, SHORT, 
INT and LONG and so the C_*_ENUM kinds would not help at all.

A function like SELECTED_ENUM_KIND may be reasonable, but rather than using
a LOW and HIGH argument, it should take a rank-1 vector which contains
*all* the enumeration constants of that enum: neither does the C standard
say that the selected integer kind does depend only on the lower and upper
values of the enumeration constants, nor does the user in all cases know
the values of these constants. For example, an enumeration RGB may be

  enum RGB { Red=1, Green=2, Blue=3 } ;

on system-1 and

  enum RGB { Red=16, Green=8, Blue=0 } ;

on another system-2. Although one *can* get it right for both cases, it is 
potentially dangerous if the values are digged out on system-1 and the 
selected kind is determined as

  SELECTED_ENUM_KIND(LOW_ENUM=Red, HIGH_ENUM=Blue)

This will break if on system-2 only the enumeration constants are ported 
to their new values but the SELECTED_ENUM_KIND is accidentially overlooked 
although it should be changed to

  SELECTED_ENUM_KIND(LOW_ENUM=Blue, HIGH_ENUM=Red)

The variant C_SELECTED_ENUM_KIND( (/ Red,Green,Blue /) ) will work for both
cases. This is still suboptimal, but a bit safer than the J3 proposal.
Should we support such an enum kind selection function?

Thanks,
Michael

 ======================================================================
  Michael Hennecke      http://www.uni-karlsruhe.de/~Michael.Hennecke/ 
 ----------------------------------------------------------------------
  University of Karlsruhe         RFC822: hennecke@rz.uni-karlsruhe.de 
  Computing Center (G20.21 R210)               No longer on BITNET :-(
  Zirkel 2  *  P.O. Box 69 80                 Phone: +49 721  608-4862 
  D-76128  Karlsruhe                               Fax: +49 721  32550 
 ======================================================================