-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?

>>18
Yes I am that person. For the last time, I know WHY there's no error there. I'm saying const is not a good language feature BECAUSE of the fact that there's no error there. It's a WTF because there's no way to tell the compiler that the int* is owned by the box such that 'const box' automatically implies 'const int* const'.

Were I a language designer, I would have made const propagate through struct pointers this way (and in fact through any indirection, so that int** const p automatically implied const int* const * const p). If the language designers attempted this and it was somehow internally inconsistent, please enlighten me; otherwise I will continue to think that they made a fucking stupid design decision with the behaviour of const.

>>20
In the second example, there is no reference; the vector is passed by value, so your comment makes no sense. I assume you thought it should look like this:

void func(const std::vector<const Box>&);

int main() {
  func(std::vector<Box>()); // ERROR, incompatible types
}

In this case, it IS a const reference, so how is your comment about non-const references relevant?

For the record I do agree that temporaries not binding to non-const makes sense, but *only* when move semantics and r-value references are available so that you can actually overload a function to take a non-const r-value parameter. Honestly move semantics should have been in the base language to begin with, not awkwardly grafted in decades late leaving other shit broken in the meantime (e.g. lack of perfect forwarding).