mikeash.com pyblog/friday-qa-2009-12-11-a-gcd-case-study-building-an-http-server.html comments

jtc - 2009-12-20 06:57:55

Sun, 20 Dec 2009 06:57:55 GMT

Thank you for a very informative series on GCD.

John

Jonathan Mitchell - 2009-12-13 20:49:09

Sun, 13 Dec 2009 20:49:09 GMT

I agree. The clang static analyser does catch it though, detecting the undefined value that results from int x = x + 1.

mikeash - 2009-12-13 17:16:31

Sun, 13 Dec 2009 17:16:31 GMT

That's not really what I want, though. That warns if you shadow a variable (and shadowing is sometimes useful) and doesn't warn if you misspelled something and thus didn't shadow a variable, but are still using a variable in its own initializer.

Jonathan Mitchell - 2009-12-13 11:44:37

Sun, 13 Dec 2009 11:44:37 GMT

void Foo(int x)
{
    if(x)
    {
        int x = x + 1; // use the parameter to initialize the local
        ...
    }
}

GCC_WARN_SHADOW, -Wshadow will give you a warning for this, if desirable.

mikeash - 2009-12-12 17:42:00

Sat, 12 Dec 2009 17:42:00 GMT

No, referring to a variable in its own initializer is perfectly legal, if frequently nonsensical. For example, I write code like this with disturbing regularity:

void Foo(int x)

{

    if(x)

    {

        int x = x + 1; // use the parameter to initialize the local

        ...

    }

}

It's legal, builds fine, and doesn't even produce any warnings. But the x that's used in the initializer is not the parameter, it is the local variable, and thus the variable is effectively uninitialized even though there is an initializer.

And in fact, gcc is perfectly happy to have a block refer to itself, too:

void Bar(void)

{

    void (^block)(void) = ^{ block(); };

}

This compiles fine, no warnings.

It also doesn't work as expected, because it captures the value of block from before the initializer occurs, thus capturing a junk value. To work around that problem, you can qualify the variable with __block, which causes the block to track changes to the variable. Works fine, except that if you initialize the block on the same line rather than on a separate line, gcc throws these bizarre errors:

test.m: In function ‘__Bar_block_invoke_1’:

test.m:16: error: request for member ‘__forwarding’ in something not a structure or union

test.m: In function ‘Bar’:

test.m:16: error: invalid type argument of ‘unary *’

Clang handles it fine, and there's nothing wrong with the code. It's just a gcc bug.

Gwynne Raskind - 2009-12-12 10:26:50

Sat, 12 Dec 2009 10:26:50 GMT

__block dispatch_source_t source; // gcc won't compile if the next line is an initializer?!

This is because you refer to source itself within the block, which you can't do in the variable's initializer because the initializer is evaluated before the declaration within the compiler; in essence, GCC doesn't know that the variable exists yet. Whether that behavior conforms to C90 or C99, I don't know.

JulesLt - 2009-12-12 08:48:14

Sat, 12 Dec 2009 08:48:14 GMT

Damn you - I'm intrigued to know how a fully developed GCD based HTTP server would benchmark against Apache now!