[RFC] PR 53063 encode group options in .opt files

Gabriel Dos Reis gdr@integrable-solutions.net
Fri May 18 13:28:00 GMT 2012

On Fri, May 18, 2012 at 4:56 AM, Chung-Lin Tang <cltang@codesourcery.com> wrote:
> On 2012/5/18 03:26 PM, Gabriel Dos Reis wrote:
>> On Fri, May 18, 2012 at 12:48 AM, Chung-Lin Tang
>> <cltang@codesourcery.com> wrote:
>>> The point here is that, a group of changes that broke C bootstrap went
>>> in undetected for several days, because of the partially C++ default. To
>>> prevent that in the future, we should enforce similar checking in both C
>>> and C++.
>> As opposed to enforcing checking that makes sense in a C++ setting?
> I think that, with the current status quo, it would be best to maintain
> things valid in both languages.

But that does not make much sense.

> But really, can you give more specific examples of "functions
> used in certain contexts [required to] have external linkage"?

struct Apply<void (*fun)() {
    // ...

// f is use only in this translation unit ...
void f() { // ..

do something with X<f>

> Because I
> don't think that in general, allowing global functions without
> declarations in headers is recommended C++ style either :)

That would only suggest a large practice of C and a limited
practice of C++.  Even our own implementation of does not
follow that practice.  It is not even idiomatic modern C++ to
require that.  It is an example of something that makes
sense in C (because

> Maybe what should be fixed is for -Wmissing-declarations to determine
> between your mentioned cases of external linkage, and the "usual" case
> (if it's not already capable of that).

This is a rabbit hole.  Your have determine
that something is useful in C, and now want at all cost
get into C++ without looking at idiomatic modern C++ and
see whether it makes much sense there.

> Chung-Lin

More information about the Gcc-patches mailing list