RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Description of problem:

Original problem can be found at https://bugzilla.gnome.org/show_bug.cgi?id=666081

This can be reduced to:

typedef int Foo;
typedef int Foo;

which on RHEL 6.2 gives

$ LC_ALL=C gcc -c typedef.c
typedef.c:2: error: redefinition of typedef 'Foo'
typedef.c:1: note: previous declaration of 'Foo' was here

The same program compiles with no errors nor warnings (-Wall -Wextra) on Fedora 16


https://bugzilla.gnome.org/show_bug.cgi?id=666081#c1 says:

"Dodji Seketeli [developer] 2011-12-13 12:59:18 UTC

Although the re-definition is unfortunate and should trigger a
warning, I think the code is valid, so this is a GCC issue.  I
believe this code is accepted in recent GCCs.  AIUI, the part of
the code in the C front-end in GCC that deals with this (in
trunk) is, in gcc/c-decl.c:

static bool
diagnose_mismatched_decls (tree newdecl, tree olddecl,
               tree *newtypep, tree *oldtypep)
{
[...]
      else if (pedantic && !flag_isoc1x)
    {
      pedwarn (input_location, OPT_pedantic,
           "redefinition of typedef %q+D", newdecl);
      locate_old_decl (olddecl);
    }
[...]
}"


Version-Release number of selected component (if applicable):

$ gcc --version
gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3)

$ rpm -q gcc
gcc-4.4.6-3.el6.x86_64

The duplicate typedefs are invalid in both ISO C89 and C99, it is only valid in the upcoming C1X standard that is being worked on.  GCC 4.6 and later allow it as an extension (except for -pedantic-errors) in preparation for C1X standard, but that doesn't change anything on it being invalid in C89 and C99, so I'm against backporting those changes to GCC 4.4 or earlier.  Just fix up your sources.

Oh ok, I assumed that this was valid C since gcc 4.6 accepted it, didn't think of the various revisions of the standard. Thanks a lot for the input, next time I'll do more homework before opening a bug.

The C specification is a source of never-ending learning to me.  :-)

So it looks like the part of the C99 specification that forbids re-declarations of typedefs is 6.7/3:

"If an identifier has no linkage, there shall be no more than one declaration of the identifier (in a declarator or type specifier) with the same scope and in the same name space, except for tags as specified in 6.7.2.3."

And typedef names are not tags.

Later, in C1X, it was decided to allow the redeclaration of typedefs of the same type in the same tag, as C++ allows: http://www.velocityreviews.com/forums/t674488-benign-typedef-definition.html.