Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!apple!apple.com!rmh
From: rmh@apple.com (Rick Holzgrafe)
Newsgroups: comp.sys.mac.programmer
Subject: Re: MPW compiler bugs (was: interface war)
Message-ID: <6792@internal.Apple.COM>
Date: 20 Feb 90 02:28:51 GMT
Sender: usenet@Apple.COM
Organization: Apple Computer, Inc.
Lines: 26
References:<1990Feb14.004350.14475@oracle.com> <10898@zodiac.ADS.COM> <34412@cci632.UUCP> <10936@zodiac.ADS.COM>

In article <10936@zodiac.ADS.COM> anders@penguin (Anders Wallgren) writes:
> The MPW C compiler optimizes the size of enums depending on what
> values they take on - if it only has ten values, all of which are less
> than the maximum value that a data size can hold, then it will make
> the enum that size.  There is no way to turn this off.
> 
> When CFront compiles your code, it makes all your enums int's,
> irregardless of what values they hold.  Apparently Apple wanted it to
> optimize enums like their C compiler does, because there is a flag to
> CFront (-z6, I think) to tell it to NOT optimize enum, but this is in
> fact what it does all the time.

I *know* it's ugly and offensive, but could you do something like:
    enum type { type1, type2, type3, typeDummy=0x7fffffff };
to force MPW C to use 32-bit values for enums? If so,
    #define FORCE_LONG_ENUMS    ,typeDummy=0x7fffffff 
    enum type { type1, type2, type3 FORCE_LONG_ENUMS};
could be used for the duration, then easily compiled out when the 
compilers get their acts together.

==========================================================================
Rick Holzgrafe              |    {sun,voder,nsc,mtxinu,dual}!apple!rmh
Software Engineer           | AppleLink HOLZGRAFE1          rmh@apple.com
Apple Computer, Inc.        |  "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 67-B |    not necessarily represent those of my
Cupertino, CA 95014         |        employer, Apple Computer Inc."