What does "Uint32 enum {a = 100, b = 200};" mean?

Discussion in 'C Programming' started by Xiangliang Meng, Jul 13, 2004.

  1. Hi, all.

    I see a very strange fragment code today.

    Uint32 enum
    {
    a = 100;
    b = 200;
    };
    NOTE: Uint32 is defined to be 'unsigned' in other source files.

    I'm sure that C standard does NOT premit to define an enumeration specifier
    like this. In addition, I did not find that GNU CC has such extension to the
    C Language, although this code is compiled by gcc. Therefore, I'm totally
    confused by this fragment code.

    Could someone explain it for me? Thanks.

    Best Regards,

    Xiangliang Meng
     
    Xiangliang Meng, Jul 13, 2004
    #1
    1. Advertising

  2. Xiangliang Meng

    Richard Bos Guest

    "Xiangliang Meng" <> wrote:

    > I see a very strange fragment code today.


    Strange indeed.

    > Uint32 enum
    > {
    > a = 100;
    > b = 200;
    > };
    > NOTE: Uint32 is defined to be 'unsigned' in other source files.


    That is a syntax error. If there's a typedef in front of it, it defines
    Uint32 as the enum in question, which would be strange in itself; since
    there isn't, it simply is not valid C.

    Richard
     
    Richard Bos, Jul 13, 2004
    #2
    1. Advertising

  3. Xiangliang Meng

    Dan Pop Guest

    In <cd0cu2$ga5$> "Xiangliang Meng" <> writes:

    >I see a very strange fragment code today.
    >
    >Uint32 enum
    >{
    > a = 100;
    > b = 200;
    >};
    >NOTE: Uint32 is defined to be 'unsigned' in other source files.
    >
    >I'm sure that C standard does NOT premit to define an enumeration specifier
    >like this. In addition, I did not find that GNU CC has such extension to the
    >C Language, although this code is compiled by gcc. Therefore, I'm totally
    >confused by this fragment code.
    >
    >Could someone explain it for me? Thanks.


    As such, it is entirely useless, because it doesn't contain a tag and it
    doesn't declare any object. As for the syntactic issue, let's ask the
    compilers (after replacing Uint32 by unsigned int):

    fangorn:~/tmp 391> gcc -ansi -pedantic test.c
    test.c:1: warning: useless keyword or type name in empty declaration
    fangorn:~/tmp 392> pgcc test.c
    PGC-W-0114-More than one type specified (test.c: 1)
    PGC-W-0150-Useless declaration (test.c: 1)
    PGC/x86 Linux/x86 3.3-2: compilation completed with warnings
    fangorn:~/tmp 393> icc test.c
    test.c(1): error: invalid combination of type specifiers
    unsigned int enum {a = 100, b = 200};
    ^

    compilation aborted for test.c (code 2)

    No compiler made any sense out of it, so how could I? ;-) Speculating:

    4 Each enumerated type shall be compatible with char, a signed
    integer type, or an unsigned integer type. The choice of type is
    implementation-defined, but shall be capable of representing
    the values of all the members of the enumeration.

    So, it looks like an extension allowing the programmer to choose the
    integer type himself, rather than leaving the choice up to the compiler.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jul 13, 2004
    #3
  4. Xiangliang Meng

    Chris Torek Guest

    >"Xiangliang Meng" <> wrote:
    >> Uint32 enum { a = 100; b = 200; };
    >> NOTE: Uint32 is defined to be 'unsigned' in other source files.


    In article <>
    Richard Bos <> writes:
    >That is a syntax error. If there's a typedef in front of it, it defines
    >Uint32 as the enum in question ...


    It is indeed a syntax error, but adding a "typedef" would not help
    either, because the syntax for "typedef" is:

    First, write an ordinary variable or function declarations.

    int a;
    char *b;
    double c[2], d;

    Each of these declares (and usually defines) the given identifier
    as an object of the given type -- "a" has type "int", "b" has
    type "char *", "c" has type "double [2]", and "d" has type
    "double".

    Next, stick a typedef in front:

    typedef int a;
    typedef char *b;
    typedef double c[2], d;

    (The last form is one that often surprises people.) These
    change the lines from meaning "declare <name> as <object> with
    type <type>" to "declare <name> as synonym for type <type>".
    Hence, "a" is now a synonym for "int", "b" is now a synonym
    for "char *", "c" is now a synonym for "double [2]", and "d"
    is now a synonym for "double".

    Now, if we do this for the "enum" above -- even after correcting
    other problems like the improper semicolons -- it has the wrong
    form:

    /* should be: typedef <existing-type> <new-alias> */
    typedef new_alias enum ...; /* wrong -- backwards! */

    To give it the right form, the identifier has to come after the
    "enum" sequence:

    typedef enum optional_tag { a = 100, b = 200 } new_alias;

    People get this backwards often, I speculate, from a perceived
    (but false) symmetry with "#define":

    #define DataType double /* new alias, then existing type */
    typedef double DataType; /* existing type, then new alias */

    Given the other syntax problems in Xiangliang Meng's original
    posting, I suspect he was copying the "mystery declaration" from
    (fuzzy) memory rather than the actual C source that used it.
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
     
    Chris Torek, Jul 13, 2004
    #4
  5. "Xiangliang Meng" <> writes:
    > I see a very strange fragment code today.
    >
    > Uint32 enum
    > {
    > a = 100;
    > b = 200;
    > };
    > NOTE: Uint32 is defined to be 'unsigned' in other source files.
    >
    > I'm sure that C standard does NOT premit to define an enumeration specifier
    > like this. In addition, I did not find that GNU CC has such extension to the
    > C Language, although this code is compiled by gcc. Therefore, I'm totally
    > confused by this fragment code.
    >
    > Could someone explain it for me? Thanks.


    No, gcc doesn't accept the above code. The semicolons are incorrect;
    they should be commas (the second one is optional).

    If you're going to post a code sample, please don't try to re-type it;
    cut-and-paste the *exact* code that you've compiled. Otherwise, we
    can't tell which errors are typos and which are relevant to your
    question.

    If I compile the following with gcc 3.3.3:

    typedef unsigned Uint32;
    Uint32 enum
    {
    a = 100,
    b = 200
    };

    I get:

    tmp.c:6: warning: useless keyword or type name in empty declaration

    (I'm not sure why it's just a warning rather than an error message,
    but the standard doesn't distinguish between different kinds of
    diagnostics. I get the same warning with "int int;".)

    If I change it to:

    typedef unsigned Uint32;
    Uint32 enum
    {
    a = 100,
    b = 200
    } obj;

    I get:

    tmp.c:6: error: two or more data types in declaration of `obj'

    It looks like an attempt to create an enumeration type with a specific
    representation, but it's not something that gcc supports.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Jul 13, 2004
    #5
  6. Xiangliang Meng

    Dan Pop Guest

    In <> Keith Thompson <> writes:

    >"Xiangliang Meng" <> writes:
    >> I see a very strange fragment code today.
    >>
    >> Uint32 enum
    >> {
    >> a = 100;
    >> b = 200;
    >> };
    >> NOTE: Uint32 is defined to be 'unsigned' in other source files.
    >>
    >> I'm sure that C standard does NOT premit to define an enumeration specifier
    >> like this. In addition, I did not find that GNU CC has such extension to the
    >> C Language, although this code is compiled by gcc. Therefore, I'm totally
    >> confused by this fragment code.
    >>
    >> Could someone explain it for me? Thanks.

    >
    >No, gcc doesn't accept the above code. The semicolons are incorrect;
    >they should be commas (the second one is optional).


    Note that he got it right in the subject line.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jul 14, 2004
    #6
  7. Hi, all

    Several points to address:

    1. I could not copy and paste the original codes, due to company's policy.
    ";" should be "," in the content.

    2. I consult an super expert on C++ in my company on this fragement code.
    His opinion is:
    " The original developer was hoping to control the underlying integral type
    used to represent the enum. There is no official way to do this in the C/C++
    standard. This tends to be a problem in C++ designs that overload methods
    based on the signedness of integral types. This is considered poor design.

    The 99r1 C compiler warns about this fragment. The 99r1 C++ compiler quietly
    accepts the fragment (which I believe is a bug).

    The gcc-3.3.1 C compiler warns about this fragment. The gcc-3.3.1 C++
    compiler generates an error for this fragment."

    3. I sent an email to one of their creators, but he could not remember why
    he did that. Those codes were created ten years ago.

    4. How those enumeration constant are used?
    They defined some constant configuration parameters as these enumeration
    constants. So they did not use the enum type to define any local variable,
    but took them as constant and used them directly.

    Thank all of you very much.

    Best Regards,

    Xiangliang Meng
     
    Xiangliang Meng, Jul 20, 2004
    #7
  8. Xiangliang Meng wrote:


    > 2. I consult an super expert on C++ in my company on this fragement code.
    > His opinion is:
    > " The original developer was hoping to control the underlying integral type
    > used to represent the enum. There is no official way to do this in the C/C++
    > standard.


    He is not even a moderate literate in C or C++, much less a "super
    expert." A "super expert" knows that not only are C and C++ different
    languages, they have completely different standards. There is no such
    thing as "C/C++"; there is certainly no such thing as "the C/C++
    standard". Rather, there are C and C++ standards. Don't believe
    anything that comes out of his mouth.
     
    Martin Ambuhl, Jul 20, 2004
    #8
  9. Hi, Martin.

    I think he just wanted to say "in the C standard or in the C++ standard".

    Best Regards,

    Xiangliang Meng

    "Martin Ambuhl" <> wrote in message
    news:...
    > Xiangliang Meng wrote:
    >
    >
    > > 2. I consult an super expert on C++ in my company on this fragement

    code.
    > > His opinion is:
    > > " The original developer was hoping to control the underlying integral

    type
    > > used to represent the enum. There is no official way to do this in the

    C/C++
    > > standard.

    >
    > He is not even a moderate literate in C or C++, much less a "super
    > expert." A "super expert" knows that not only are C and C++ different
    > languages, they have completely different standards. There is no such
    > thing as "C/C++"; there is certainly no such thing as "the C/C++
    > standard". Rather, there are C and C++ standards. Don't believe
    > anything that comes out of his mouth.
     
    Xiangliang Meng, Jul 20, 2004
    #9
  10. Martin Ambuhl <> writes:
    > Xiangliang Meng wrote:
    > > 2. I consult an super expert on C++ in my company on this fragement code.
    > > His opinion is:
    > > " The original developer was hoping to control the underlying
    > > integral type used to represent the enum. There is no official way
    > > to do this in the C/C++ standard.

    >
    > He is not even a moderate literate in C or C++, much less a "super
    > expert." A "super expert" knows that not only are C and C++ different
    > languages, they have completely different standards. There is no such
    > thing as "C/C++"; there is certainly no such thing as "the C/C++
    > standard". Rather, there are C and C++ standards. Don't believe
    > anything that comes out of his mouth.


    That may a little harsh. In the jargon of this newsgroup, "C/C++"
    refers to a mythical language with some undefined relationship to C
    and/or C++, with the side effect of marking the person using the term
    as ignorant. Out in the real world, "the C/C++ standard" could
    conceivably mean "the C standard or the C++ standard".

    It's clumsy and incorrect, but it may be just informal rather than
    incurably ignorant.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Jul 20, 2004
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Pratip Mukherjee

    Help: what does this VHDL code mean?

    Pratip Mukherjee, Jun 22, 2005, in forum: VHDL
    Replies:
    16
    Views:
    1,308
    Kim Enkovaara
    Jun 27, 2005
  2. methi
    Replies:
    1
    Views:
    904
    info_
    Jun 23, 2005
  3. Li Ma
    Replies:
    1
    Views:
    2,363
    Roedy Green
    Mar 9, 2009
  4. Rahul
    Replies:
    4
    Views:
    624
    Robert Kern
    Apr 7, 2009
  5. C Barrington-Leigh
    Replies:
    1
    Views:
    1,281
    Tim Leslie
    Sep 10, 2010
Loading...

Share This Page