India's population is approximately 4.5 times that of USA, so the actual ratio is "one American is emitting 35 Indians worth of carbon emissions".

These numbers are already per capita, so the population difference is already accounted for.

So one USian emits as much as 9 Indians. Which is still a lot.

bc calculator doesn't (or didn't) define pi, but has atan. I've used "4*atan(1) method" in bc to get pi.

This works, `echo 'scale=100;4*a(1)' | bc -lq`

Hobbes: Do you have an idea for your project yet?

Calvin: No, I'm waiting for inspiration. You can't turn on creativity like a faucet. You have to be in the right mood.

Hobbes: What mood is that?

Calvin: Last-minute panic.

A very common idiom is "T p = malloc(n sizeof *p)". That only works if sizeof doesn't evaluate its arguments.

Why not? Suppose you have a C99 VLA object, and you want to malloc the equivalent amount of space. Couldn't you just do this:

   int vla[nparam];
   int *pcopyspace = malloc(sizeof vla);

Here sizeof vla is basically just nparam sizeof(int).

vla* is evaluated to the extent of calculating its run-time size.

A more correct version might be:

    #include <stddef.h>

    int buf_offset = (int)offsetof(struct sdshdr, buf);
    struct sdshdr *sh = s - buf_offset;

This is because the compiler might insert padding between your struct elements and the flexible array member. In your case, you're using only int types in the header, so padding shouldn't be an issue on most architectures, but consider the following:

    struct header {
        int i;
        char c;
        char data[];
    };

sizeof(struct header) on my machine is 8, but "data" starts at an offset of 5 from the beginning of the struct. So, to go from "data" pointer to the pointer representing the beginning of the struct, you will need to subtract 5, not 8. Here is a test program:

    #include <stdio.h>
    #include <stddef.h>

    struct header {
        int i;
        char c;
        char data[];
    };

    int main(void)
    {
        struct header h = {0};
        printf("offsetof %zu\n", offsetof(struct header, data));
        printf("sizeof %zu\n", sizeof h);
        printf("start %p, data start %p, delta %d\n",
                (void *)&h, (void *)(h.data), (int)((char *)h.data - (char *)&h));

        return 0;
    }

http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n983.htm is relevant for this case as well.

Thank you for that.

That surprised me. I thought( and read somewhere ) that the flexible array member comes right after the entire struct, which includes possible padding.

OP got away with it since he always allocates the size of the entire struct, which is 8, plus the string size. And since char doesn't have any alignment requirements it doesn't matter, because he always gets back to correct offset. So data member is basically not used, and if you check the code you will see that it actually in never used!

The standard actually specifies (or specified?) that the flexible array member must come after all the members, including the padding. But, from my reading, that wasn't their intent, and is certainly not how compilers implement it. The link in my original post is an acknowledgement from the committee about this and that the standard needs to be updated.

I think the main reason the OP got away with it is because in his structure, "sizeof(struct sdshdr)" is equal to the offset of "buf" in the struct. This is not necessarily true.

In particular, see the latest C standard draft (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf), section 6.7.2.1 (Structure and union specifiers), paragraph 18 and 20-21. An example in the standard uses this code:

    struct s { int n; double d[]; };

and says that "but it is possible that"

    sizeof (struct s) >= offsetof(struct s, d) + sizeof (double)

Yeah I was wrong on that, he must have sizes 8 both. My compiler gives 5 and 8.

Coincidentally I just read that specific paragraph earlier today for totally different reasons. :)

Will have to recheck some code.

Very true of course, I guess I assumed that antirez had thought of that, should have noticed that there were no packing enhchantmens on the struct. I love offsetof() for code like this.