Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[C DR423] Clang does not use the unqualified version of return type for C17 program #39494

Open
yeah-boi mannequin opened this issue Dec 23, 2018 · 5 comments
Open

[C DR423] Clang does not use the unqualified version of return type for C17 program #39494

yeah-boi mannequin opened this issue Dec 23, 2018 · 5 comments
Labels
bugzilla Issues migrated from bugzilla c11 clang:frontend Language frontend issues, e.g. anything involving "Sema" confirmed Verified by a second party rejects-valid

Comments

@yeah-boi
Copy link
Mannequin

yeah-boi mannequin commented Dec 23, 2018

Bugzilla Link 40147
Version trunk
OS All
CC @pascal-cuoq,@hfinkel,@zygoloid

Extended Description

Test case (prog.c):

  int main()
  {
    typedef const int t();
    typedef int t();
  }

Compilation command line:

  clang prog.c -Wall -Wextra -std=c11 -pedantic-errors 

Observed behaviour:

The following error message was outputed:

    error: typedef redefinition with different types ('int ()' vs
           'const int ()') typedef int t();

Expected behaviour:

No error message. Both typedefs should define t to be of type 'int ()' since
function types never have qualified return types.

Standard references:

6.7.6.3.5

Note:

gcc does not give any errors for the program.

@zygoloid
Copy link
Mannequin

zygoloid mannequin commented Dec 23, 2018

Standard references:

6.7.6.3.5

Do you mean 6.7.6.3/5? That seems to justify Clang's current behavior:

"If, in the declaration ‘‘T D1’’, D1 has the form D( parameter-type-list ) or D( identifier-list[opt] ) and the type specified for ident in the declaration ‘‘T D’’ is ‘‘derived-declarator-type-list T’’, then the type specified for ident is ‘‘derived-declarator-type-list function returning T’’."

... which says that the first typedef declares t as ‘‘function returning const int’’ and the second typedef declares t as ‘‘function returning int’’. Moreover, 6.7.6.3/15 says

"For two function types to be compatible, both shall specify compatible return types."

(And 6.7.3/10: "For two qualified types to be compatible, both shall have the identically qualified version of a compatible type;")

As far as I can see, Clang is correct here: type-qualifiers on the return type are part of the function type and are not ignored when determining whether two function types are compatible.

So I think this is a GCC bug (or maybe extension).

@yeah-boi
Copy link
Mannequin Author

yeah-boi mannequin commented Dec 24, 2018

Yes, 6.7.6.3/5.

I have look at the standard again now and it seems like there is a difference between the C11 standard and the C17 (the bugfix for C11).

In the C11 standard 6.7.6.3/5 looks like the way you quoted, but in the C17 (
the bugfix for C11) looks it like the following:

If, in the declaration “T D1”, D1 has the form D(parameter-type-list) or
D(identifier-list[opt]) and the type specified for ident in the declaration
“T D” is “derived-declarator-type-list T”, then the type specified for ident
is “derived-declarator-type-list function returning the unqualified version of
T”.

So in the C11 standard the return type is stated to be "T", but in the C17 standard (the bugfix for C11) the return type is stated to be "the unqualified version of T".

Latest draft of the C17 standard (the bugfix for C11):

http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf

@zygoloid
Copy link
Mannequin

zygoloid mannequin commented Dec 24, 2018

Thanks, this is C11 DR 423:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_423

... which Clang evidently does not yet implement.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 10, 2021
@Quuxplusone Quuxplusone added the confirmed Verified by a second party label Feb 10, 2022
@AaronBallman AaronBallman added c11 clang:frontend Language frontend issues, e.g. anything involving "Sema" rejects-valid and removed clang Clang issues not falling into any other category labels Jun 18, 2023
@llvmbot
Copy link
Collaborator

llvmbot commented Jun 18, 2023

@llvm/issue-subscribers-c11

@llvmbot
Copy link
Collaborator

llvmbot commented Jun 18, 2023

@llvm/issue-subscribers-clang-frontend

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla c11 clang:frontend Language frontend issues, e.g. anything involving "Sema" confirmed Verified by a second party rejects-valid
Projects
None yet
Development

No branches or pull requests

3 participants