Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ncar!ico!ism780c!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: problem with cc compiler
Message-ID: <14182@haddock.ima.isc.com>
Date: 3 Aug 89 15:02:26 GMT
References: <712@unsvax.NEVADA.EDU> <10589@smoke.BRL.MIL> <1185@fcs280s.ncifcrf.gov> <3100@scolex.sco.COM> <10620@smoke.BRL.MIL> <3109@scolex.sco.COM> <10633@smoke.BRL.MIL>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 17

In article <10633@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>In article <3109@scolex.sco.COM> seanf@scolex.UUCP (Sean Fagan) writes:
>>C related notice:  has anybody but myself noticed that the current dpANS
>>does not seem to require that the implementation-dependent (or defined)
>>options can change between modules?  Provided everything works, ...
>
>So long as the implementor is able to specify the required information,
>indeed arbitrarily complex rules could be adopted.

Here's an example where such flexibility is useful: it allows the
"implementation-defined" equivalent-type of a enum to be "the narrowest
integral type that's capable of containing all values of the enumeration
constants".  Thus on such an implementation, enum {RED,BLUE,GREEN} would be
stored in a char-sized object, while still allowing for the existence of
large-range enums, which would be stored in a full word.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint