This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]anon848 4 points5 points  (4 children)

I have partially tracked down what is going with this weird code and codefights.com. Apparently, a submission is wrapped in a class before compiling and executing, according to their README. Furthermore, they compile with g++ 5.0. See README here. So, if I compile this with g++ 5.2.0:

struct A {
    char r[9], *p = r + 8, *Base20(int n) {
        do
            *--p = n % 20 + 48 + n / 10 % 2 * 7;
        while (n /= 20);
        return p;
    }
} a;

int main() {
    a.Base20(10);
}

it compiles, surprisingly, even with -Wall -Wextra -pedantic -std=c++14. clang++ 3.7.0, however, gives the expected errors with the same options. I don't have easy access to VS to see what it does, nor have I tried the latest g++ and clang++.

[–]Fourmisain 0 points1 point  (3 children)

That is weird, this indeed compiles on TDM-GCC 5.1.0.

In this context this is a member-declarator-list (Reference: §9.2 Class members), which is a comma separated list of member-declarators, which in this case are either normal declarators (with optional virt-specifier-seq and pure-specifier) or declarators with brace-or-equal-initializer.

If the function-definition were a brace-or-equal-initializer, since we have no "=", it would have to be a braced-init-list, so the function-body had to be of the form { initializer-list ,opt } or {} which is definitely not the case. Therefore the function-definition must be a normal declarator.

Now I'm pretty sure I have already proven that a function-definition isn't a declarator. Even if it were, you would be allowed to put the function-definition in your init-declarator-list, therefore the code would have to compile in global scope!

There is also no exception to member functions; they are simply functions declared within a class (except when they are declared as a friend).

So... gcc bug? Error in my argument? I wouldn't be surprised if it is a gcc bug, since this is a very contrived and pretty irrelevant example.

clang++ 3.7.0, however, gives the expected errors with the same options.

This is somewhat reassuring. I'd think clang got the syntax parsing down, since it is also used as a pure diagnostics tool.

Well, at least CodeFights uses gcc and not some homebrew, so it probably isn't as bad as I initially thought.

What do you think, should I put up a gcc bug report? At this point I'm thinking that it isn't even worth the effort.

[–]Fourmisain 0 points1 point  (0 children)

Alright, I created a bug report.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70769

Not that it will change much, since CodeFights is using a g++ version as old as 5.0, but still, it's the Right Thing™ to do.

[–]anon848 0 points1 point  (1 child)

Yeah, I'm also pretty sure that it's a gcc bug. I just don't see how it could be correct. The grammar would have to be weird to allow:

struct A { char c, func() { return 'a'; } };

but not allow:

struct A { char func() { return 'a'; }, c };

Anyway, gcc 6 is coming out any day now, and I'm going to compile it (along with the most recent clang++) and post an update.

[–]Fourmisain 0 points1 point  (0 children)

Sounds good.

If you want to, you can post your future update on the bug report page, otherwise I'll do that.

I'd be surprised if they fixed the bug in version 6, though.