Question about enum

[Jens Staal]

Hi

One issue that I currently have is that Watcom errors out on some enum
expressions in a header file, for example:

Error! E1009: Expecting '}' but found '7'
Error! E1026: Invalid declarator

(and so on for the following rows)

typedef enum _ARC_CODES
{
ESUCCESS,
E2BIG,
EACCES,
EAGAIN,
EBADF,
EBUSY,
EFAULT,
EINVAL,
EIO,
EISDIR,
EMFILE,
EMLINK,
ENAMETOOLONG,
ENODEV,
ENOENT,
ENOEXEC,
ENOMEM,
ENOSPC,
ENOTDIR,
ENOTTY,
ENXIO,
EROFS,
EMAXIMUM
} ARC_CODES


I have read the style instructions at
http://www.openwatcom.org/index.php/Style_Guide

and I have tried removing the _ARC_CODES thing before the {} and I have also
tried with putting all the elements in a single row (if line break was the
issue). I have also tried this trick:

#if defined(__WATCOMC__)
#pragma enum int
#endif

and neither solves the issue.

Is there something that I have missed?

[Tomasz Kępczyński]

Post by Jens Staal
Hi
One issue that I currently have is that Watcom errors out on some enum
Error! E1009: Expecting '}' but found '7'
Error! E1026: Invalid declarator
(and so on for the following rows)
typedef enum _ARC_CODES
{
ESUCCESS,
E2BIG,
EACCES,
EAGAIN,
EBADF,
EBUSY,
EFAULT,
EINVAL,
EIO,
EISDIR,
EMFILE,
EMLINK,
ENAMETOOLONG,
ENODEV,
ENOENT,
ENOEXEC,
ENOMEM,
ENOSPC,
ENOTDIR,
ENOTTY,
ENXIO,
EROFS,
EMAXIMUM
} ARC_CODES
I have read the style instructions at
http://www.openwatcom.org/index.php/Style_Guide
and I have tried removing the _ARC_CODES thing before the {} and I have also
tried with putting all the elements in a single row (if line break was the
#if defined(__WATCOMC__)
#pragma enum int
#endif
and neither solves the issue.
Is there something that I have missed?

You are trying to reuse at least some of the names used for errno
values. They are probably #defined somewhere and hence the 7 substituted
by preprocessor.

It will not work. Why not name them like ARC_<something>?

Tomek

[Peter Chapin]

Post by Jens Staal
One issue that I currently have is that Watcom errors out on some enum
Error! E1009: Expecting '}' but found '7'
Error! E1026: Invalid declarator

As Tomasz points out some of the symbols you are using are no doubt
object-like macros. Declarations such as

enum X { 1, 2, 3 };

are illegal and that's what the compiler is seeing in your case. This is
a nice example of why the preprocessor is evil. I therefor applaud you
for trying to use an enumeration. Unfortunately there is a lot of C out
there that uses #define.

Peter

[Paul S. Person]

Post by Jens Staal
Hi
One issue that I currently have is that Watcom errors out on some enum
Error! E1009: Expecting '}' but found '7'
Error! E1026: Invalid declarator
(and so on for the following rows)
typedef enum _ARC_CODES
{
ESUCCESS,

<etc>

Post by Jens Staal
} ARC_CODES

Well, the last line should be

Post by Jens Staal
} ARC_CODES;

(note the semicolon at the end), as shown in the Style Guide.

Post by Jens Staal
typedef enum _ARC_CODES

could just as well be

Post by Jens Staal
typedef enum ARC_CODES

as typedefs are a separate name space from enums, structs and unions.

Unless you are planning to use "enum _ARC_CODES" in declarations
(function parameters, for example), there is no need to name the enum
as such; the typedef name is what you will be using anyway. The Style
Guide shows no enum name when typedef is used, just the typedef name.

Using prefixes is helpful not only in allowing you the freedom of
reusing the obvious tag names (since the prefix makes them distinct)
but (if you use prefixes reminiscent of the enum name) also as a
memory-aid: the prefix reminds you which enum the tag belongs to.

[Jens Staal]

Post by Paul S. Person
Using prefixes is helpful not only in allowing you the freedom of
reusing the obvious tag names (since the prefix makes them distinct)
but (if you use prefixes reminiscent of the enum name) also as a
memory-aid: the prefix reminds you which enum the tag belongs to.

Thanks all for the feedback! I did now change the enum with some prefixes in
the form of:

...
ARC_EACCES = EACCES,
...

and this worked :)

The background to the problem is that I am trying to compile a big project
(ReactOS) using OW. The code is made to build with either GCC (MinGW) or
MSVC so apparently OW is more strict than those compilers when it comes to
enums.

I have now run into another hairy problem but I think that one fits better
in a sepparate thread

[Hans-Bernhard Bröker]

Post by Jens Staal
The background to the problem is that I am trying to compile a big project
(ReactOS) using OW. The code is made to build with either GCC (MinGW) or
MSVC so apparently OW is more strict than those compilers when it comes to
enums.

Unlikely. A more likely root cause for that problem is that you didn't
set up the compiler flags and OW environment variables correctly to make
sure you get only the ReactOS headers, instead of the ones supplied by
the compiler itself.

Building the C runtime support for an OS from scratch is one of the few
cases where it is OK to make your own definitions of standard symbols
like EACCESS.

[Hans-Bernhard Bröker]

Post by Jens Staal
One issue that I currently have is that Watcom errors out on some enum
Error! E1009: Expecting '}' but found '7'
Error! E1026: Invalid declarator

While those errors are triggered _in_ an enum definition, they're almost
certainly not actually _about_ it.

You'll see the difference once you run the preprocessor on your source
and look at the output around the line in question, i.e. instead of

wcc386 {..options..} foo.c

do

wcc386 {..options..} -pc -fo=foo.i foo.c
wcc386 {..options..} foo.i

The line number of the error message will now point to a line in foo.i,
which in turn will show you what actually became of your source after
#include, #if and macros have been handled. To see which source line
the broken line actually came from, replace '-pc' by '-pcl'.

This technique of looking at preprocessor output is sometimes the only
way to make sense out of some of the quizzical errors in C programs.

Post by Jens Staal
EACCES,

You're trampling over predefined library names. Completely unprefixed
enum names like that do fail the rear end of Einstein's saying: "Keep it
as simple as possible --- but no simpler!"

As a highly recommendable coding guideline to avoid such nasty surprises
in the future, any enum values you define should have some kind of
prefix that disambiguates them. This is usually achieved by putting
information about you, your company, the programming project, the
purpose of the enum or even the timestamp of their original creation, or
some combination thereof into the name of each enum entry. E.g.
something like

typedef enum FOOCORP_BARMODULE_BAZTYPE {
E_FOOCORP_BARMODULE_BAZTYPE_VALUENAME1,
E_FOOCORP_BARMODULE_BAZTYPE_VALUENAME2,
E_FOOCORP_BARMODULE_BAZTYPE_VALUENAME3
} FOOCORP_BARMODULE_BAZTYPE;

[Wilton Helm]

Sadly, the weak typing of C makes all enums fall into a single namespace.
Not only does this allow problems like this to accidentally show up, but it
also allows enums to be used in contexts they were never intended to and
forces the verbose FOOCORP_BARMODULE_BAZTYPE type nonsense that HB
illustrated. Not nonsense on HBs part, but nonsenses because if it were
restricted to variables of that type, then the qualifiers in the name would
not be necessary.

Wilton

[Paul S. Person]

On Thu, 20 Mar 2014 10:35:37 -0600, "Wilton Helm"

Post by Wilton Helm
Sadly, the weak typing of C makes all enums fall into a single namespace.
Not only does this allow problems like this to accidentally show up, but it
also allows enums to be used in contexts they were never intended to and
forces the verbose FOOCORP_BARMODULE_BAZTYPE type nonsense that HB
illustrated. Not nonsense on HBs part, but nonsenses because if it were
restricted to variables of that type, then the qualifiers in the name would
not be necessary.

This is true, but it is also Standard.

Note: you don't have to use excessively long prefixes. Unless you need
to distinguish "foocorp" from "feecorp", you don't need that at all;
and unless you you need to distinguish "barcorp" from "barkeeper",
then "bar_" will work just fine. Similarly, unless you are
distinguising "baztype" from "bazvar", "baz" would do just as well,
particularly if /all/ the tags in that enum are "types".

Well, you don't unless your employer's style guidelines /require/ you
to use excessively long prefixes.

C++ takes an alternate approach; however, while in most (in my limited
experience) contexts you could use simply "baztype", in others you
would need "foocorp_barcorp::baztype" (if "baztype" is used in any
other enum). You get what you pay for.