-std=c99 my anus

[code]$cat test.c
#include <stdlib.h>
#include <string.h>

int main(void) {
    char *foo;
    foo = strdup("bar");
    free(foo);
    return 0;
}
$gcc test.c
$gcc -std=c99 test.c
test.c: In function 'main':
test.c:6: warning: implicit declaration of function 'strdup'
test.c:6: warning: assignment makes pointer from integer without a cast[code]
What the heck is this, /prog/? Is there some shit around strdup() in c99?

>>33
I sometimes, but rarely, have issues with optimized-out values with -O; with -O2 or so, it does become a more frequent problem. These can usually be resolved by temporarily peppering 'volatile' around the pertinent area (and then a :%s~volatile ~~ afterward to clean up). Sucks but that way you get warnings about useless and unused variables, and a couple other classes of warnings that never come up unless the code gets run through the optimizer. I'm sure there is some way to get the benefits of the warnings without incurring many of the hindrances to debugging, but I simply have never bothered narrowing down from the flags set by -O to the minimal subset necessary to enable those warnings, as it works well enough for me already.

>>34
Try it with the example here, and you will find that writing to the fields is still permitted regardless of which part of the struct variable declaration is const. The underlying problem is that the fields inside the struct aren't const just because the struct is -- with either const box_t *foo or box_t *const foo, the int * is still not a const pointer, and surely is not pointing to const data. It's the same as char **foo versus char *const *foo versus char **const foo, except you're only capable of defining the top level const without defining a different, technically-incompatible struct. In this case you'd still need another "const box" type, which is not possible in C. Try it.