From malcolm@nag.co.uk Tue Jul 8 14:37:33 1997 Received: from red.nag.co.uk ([192.156.217.2]) by dkuug.dk (8.6.12/8.6.12) with SMTP id OAA15790 for ; Tue, 8 Jul 1997 14:37:15 +0200 Received: from sedi8.nag.co.uk by red.nag.co.uk via SMTP (920330.SGI/920502.SGI) for SC22WG5@dkuug.dk id AA19915; Tue, 8 Jul 97 13:37:15 +0100 Received: by sedi8.nag.co.uk (920330.SGI/920502.SGI) for @red.nag.co.uk:SC22WG5@dkuug.dk id AA25242; Tue, 8 Jul 97 13:36:52 +0100 From: malcolm@nag.co.uk (Malcolm Cohen) Message-Id: <9707081236.AA25242@sedi8.nag.co.uk> Subject: Re: (SC22WG5.1395) C enum support To: SC22WG5@dkuug.dk Date: Tue, 8 Jul 1997 13:36:51 +0000 (BST) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 841 Michael Hennecke said: > 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. You expectation is incorrect - the C standard allows enum types to be wider and it is very common for a compiler to make an enum type effectively "int" even though all the values fit into a char/short/whatever. (On such compilers, C_SCHAR_ENUM, C_SHORT_ENUM and C_INT_ENUM would all be equal to C_INT). Given that, SELECTED_ENUM_KIND might be overkill, though it would certainly be more useful than nothing. Cheers, -- ...........................Malcolm Cohen, NAG Ltd., Oxford, U.K. (malcolm@nag.co.uk)