On Mon, Jun 17, 2013 at 9:21 AM, Douglas Gregor <[email protected]> wrote: > > On Jun 11, 2013, at 6:02 AM, Rafael Espíndola <[email protected]> > wrote: > > On 10 June 2013 19:08, Rafael Espíndola <[email protected]> wrote: > > Richard pointed out on IRC that the patch should look at the > redeclaration context to avoid problems with one of the functions > being in a extern "C++". Implementing that found some interesting > problems. Consider > > extern "C" { > static void foo(int x); > static void foo() { > } > void foo(int x) { > } > } > > This should be valid, since both functions have internal linkage and > therefore none of them has C language linkage. Commenting the first > declaration makes the code invalid as now the last one is extern C and > [dcl.link] p6 kicks in. This means we have to do "normal" overload > resolution first to see if the last decl we are looking at has C > language linkage or not. > > > BTW, is this sufficient evidence that we should just give static > functions C language linkage? I just checked http://gcc.godbolt.org/ > and gcc 4.8 and icc 13 (which is edg based, no?), reject > > extern "C" { > static void foo() { > } > static void foo(int x) { > } > } > > We are putting quiet a bit of effort to make sure we accept it and I > still can't see the value. > > > I, too, find this behavior strange. Changing between static and non-static > shouldn’t affect whether a function can be overloaded; it’s completely > non-intuitive and apparently at odds with existing practice in GCC/EDG.
The latter, at least, is not the case; EDG accepts this code in both its compliant mode and in its g++-compatible mode. I'm surprised that ICC rejects this. The former makes some degree of sense to me -- a 'static' declaration doesn't have external linkage and thus doesn't have C linkage -- although I agree that it's weird. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
