enums with 0x8000 assignment in ORCA/C 2.2.0 B4 fail to compile with an "integer overflow" error

[xandark]

I am compiling my huge code base from 1995. This simple code snippet fails to compile with ORCA/C 2.2.0 B4 with an "integer overflow" error.

It appears that it doesn't like enum's with const assignments to 0x8000, but assignment to -1 seems to be fine. Has this been fixed in later versions? I see there's a lot of new cool stuff since Feb 2020 (hint, hint for a newer release :)

enum SomeEnums          {noflags = 0, allflags = -1};    /* this compiles ok */

enum SysErrorKind       {errNone, errStandard = 0xFFFF, errMemory = 0x0201, errVersion = 0x0099};  /* this fails */

enum WindowFlags        {windowFlagNone         = 0x0000,
                        windowFlagVisible       = 0x0001,
                        windowFlagFullScreen    = 0x0002,
                        windowFlagResizable     = 0x0004,
                        windowFlagUpdated       = 0x0008,
                        windowFlagGS320Mode     = 0x8000};   /* this fails */

void ignore( void ) { ; }

[sheumann]

I believe this is working as intended, although the error message could be clearer. Specifically, it is enforcing the following constraint from the C language standards:

The expression that defines the value of an enumeration constant shall be an integer constant expression that has a value representable as an int.

Since int is a 16-bit signed type in ORCA/C, 0x8000 is outside the range of values that it can represent, and therefore the compiler is correct to report an error.

Supporting larger enumeration constants might be a useful extension, but I have no specific plans for that at this time. For your purposes, it may work to just use the corresponding negative values, either by writing them directly or by casting to int.

[xandark]

Okay, interesting, I guess I got away with a compiler bug all those years ago. Well thanks for getting back to me. I'll make the change and recompile with 2.2.0 B4. What are the devs' plans to release newer versions?

[MikeW50]

Hi,

“Fixed” speaks volumes about assumptions. It was never broken. The code is making invalid assumptions about the size of int and enum. The compiler is fine.

You might try 0x008000, forcing the value from int to long.

Mike

Mike Westerfield PADI Master Instructor 170184 PADI Tec Deep Instructor HSA Instructor 4131 505-280-3998

On Jun 27, 2021, at 10:03 PM, xandark @.***> wrote:

I am compiling my huge code base from 1995. This simple code snippet fails to compile with ORCA/C 2.2.0 B4 with an "integer overflow" error.

It appears that it doesn't like enum's with const assignments to 0x8000, but assignment to -1 seems to be fine. Has this been fixed in later versions? I see there's a lot of new cool stuff since Feb 2020 (hint, hint for a newer release :)

enum SomeEnums {noflags = 0, allflags = -1}; / this compiles ok /

enum SysErrorKind {errNone, errStandard = 0xFFFF, errMemory = 0x0201, errVersion = 0x0099}; / this fails /

enum WindowFlags {windowFlagNone = 0x0000, windowFlagVisible = 0x0001, windowFlagFullScreen = 0x0002, windowFlagResizable = 0x0004, windowFlagUpdated = 0x0008, windowFlagGS320Mode = 0x8000}; / this fails /

void ignore( void ) { ; } — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/byteworksinc/ORCA-C/issues/73, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYWYUGFSJRNMEX657IGZBDTU7YADANCNFSM47NEDFHQ.

[xandark]

Hello Mike,

Thank you for commenting. I am truly grateful I learned C using your products, they were so clear.

So sorry if I offended you, it wasn't my intent. I just don't understand why code similar to this was compiling just fine in the 90's using Orca/C 2.1:

enum WindowFlags {windowFlagNone      = 0x0000,
                  windowFlagGS320Mode = 0x8000};

...yet compiling that snippet with the github Orca/C 2.2 fails. And I did change it to 0x008000 but I still get the "integer overflow" error. 0x8000L and same issue. The only way to appease the compiler is to cast 0x8000 to int. Which is acceptable to me.

[MikeW50]

Gosh, I really didn't mean to sound offended. I hate text communications at times. I was just trying to point out that odd corner cas in C vs Unix--int really isn't 4 bytes. :)

Mike

Mike's iPhone

On Jun 29, 2021, at 5:53 PM, xandark @.***> wrote:

 Hello Mike,

Thank you for commenting. I am truly grateful I learned C using your products, they were so clear.

So sorry if I offended you, it wasn't my intent. I just don't understand why code similar to this was compiling just fine in the 90's using Orca/C 2.1:

enum WindowFlags {windowFlagNone = 0x0000, windowFlagGS320Mode = 0x8000}; ...yet compiling that snippet with the github Orca/C 2.2 fails. And I did change it to 0x008000 but I still get the "integer overflow" error. 0x8000L and same issue. The only way to appease the compiler is to cast 0x8000 to int. Which is acceptable to me.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.