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

fuck, pardon my lack of bbcode skills

If by “some shit around” you mean that this non-standard extension is not enabled in strict c99 mode, then yes. Use gnu99 or use a real language like Lisp.

Use C89 because C99 is silly and bloated

>>4
Enjoy declaring variables at the beginning of a scope.

>>5
I will, along with my job

>>4
Hear, hear! Real programmers don't eat quiche, and they certainly don't use any of this newfangled C99 shit.
Complex programmers on the other hand...

C99 is awesome. It's basically a standardization of features that have been common extensions for decades.

The only thing that's not awesome is const. It was broken in sepples, and it's even more broken now...

>>8
The only thing that's not awesome is const. It was broken in sepples, and it's even more broken now...
How so?

It's broken because it does not propagate.

typedef struct box {
  int* p;
} box_t;

void func(const box_t* box) {
  box->p[0] = 5; // WTF NO ERROR!! hax mah box
};

Here's another example:

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

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

It's broken because attempts to fix it (in sepples) cause code duplication due to permutations of const arguments ('const-overloading').

class BoxList {
const Box& operator[] (int i) const;
      Box& operator[] (int i);
}

It's even more broken in C because the above hacks aren't allowed.

>>10
Learn what 'const' means, and what your const is really referring to.

Also the const keyword in C++ is such an abomination.

>>11
I'd const my dick into... wait, fuck that.

>>11
I know how it works shitface. My point is that it's worse than useless. It does not work the way you would expect or want.

>>13
Works fine in C for me, what's the problem?

>>10
It works exactly how I expect; maybe you have been brain damaged by too many stupid languages to understand pointers. The data you are manipulating is not const, your box is. If you don't want your code to work, make your int pointer const, not the box.

>>15
The data you are manipulating is not const, your box is.
THAT'S THE PROBLEM. Christ, I know how they fucking work. Why don't you explain to me again what is const?

make your int pointer const, not the box.
No, you can't do that. If you make the int point to const in the struct, then the implementation of the box can't ever modify it. You can't make two boxes (i.e. Box, with int* and ConstBox with const int*) because they're inconvertible.

That's the whole problem, don't you see? There's no way to make a const box where the const is propagated to its pointers. Yes, they fucking work according to the spec, we get it. The spec is BAD. It was a BAD DECISION to make them work the way they do.

But go ahead, explain to me again how the int is not constant but the box is.

>>16
ergo your wrong bitch

>>16
Are you really the same person who wrote // WTF NO ERROR!! hax mah box? It's no wonder everyone you wouldn't know how const works.

struct Box {
  int* getp();
  void setp(int*);
  int const* getp() const;
private:
  int* p;
};

There's the Sepples ``solution''. It fits nicely with the rest of Sepples, with its PIG DISGUSTINGness.

>>10
sry but I gotta agree with everyone else; you're a fgt. how is the second example "broken"? temporaries not binding to non-const references makes sense to me.

>>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).

>>21
apologies, I'm >>20, next time tell me not to read code drunk. that said, now that I'm sober, while the original accusation is unfounded, of course they are still incompatible types because I can specialize on the const qualifier. observe

template<typename T>
struct something { int a; };

template<typename T>
struct something<const T> { double a; };

clearly a something<int> is not equivalent to a something<const int>, so you can't cast the two types implicitly. how is this not what should be the expected behavior fgt

>>21
Yes, all things are horrible because they can be misused by idiots. Let's go back to pounding rocks together in caves.

>>22
of course they are still incompatible types because I can specialize on the const qualifier. observe
God damnit, another one explaining to me the rules of const, as though I don't understand them. Specializing a template on const would not be necessary if the const was propagated. If the implicit cast was allowed, then upon implicitly converting a something<T> to something<const T>, the compiler could automatically instantiate the const template, and the template functions that don't respect the const simply wouldn't be compiled into the copy (SFINAE).

>>23
You'd rather we just work with what we have and never try to improve anything? No need to invent a screwdriver folks, we already have hammers.

>>24
woosh!

>>24
you're a moron. you're talking as if the only possible differences between a <T> template and its <const T> specialization are, well, that every time a T is used in the original template, the same code is replicated in the <const T> specialization but just with a "const" in front of all Ts. tell me, how does this fantasy language of yours deal with a conversion between somethings, e.g.
something<const int> a = something<int>();
does it convert the int a to double a? what if I called it double b, would the compiler magically still link int a to it?

understand that your suggestion is also tantamount to saying we should implicitly allow stuff like
something<double> a = something<int>();
y'know, I mean, I can do double f = 3;, so why can't my templates implicitly convert between these types as well.

What on Earth? In what context would something<const int> be useful?

>>27
who knows. the point is, the language allows it, and it allows me to partially specialize templates based on whether the type passed to a template is const or not.

>>26
you're talking as if the only possible differences between a <T> template and its <const T> specialization are, well, that every time a T is used in the original template, the same code is replicated in the <const T> specialization but just with a "const" in front of all Ts.
Yes, if C++ was like this, const would be wonderful. In my 'fantasy language', a const specialization *would not be allowed*, because it would not be necessary; the const version would be generated implicitly (really it's the same code, just with compile-time const checking) so it would have the same class layout.

understand that your suggestion is also tantamount to saying we should implicitly allow stuff like something<double> a = something<int>();
No, of course it it's not you fool. something<const int> would necessarily have the same class layout as something<int> because it's not a different class; it's the same code, just const-checked at compile time.

does it convert the int a to double a?
If you think you should be able to change your int to a double based on a const specialization, then you're fucking retarded. The fact that you are happy that such a hack to be possible is the true mark of a sepples programmer. There is no hope for you.

Alright, as >>10-chan here, let me take a step back and try to gather everyone's thoughts. Here are two mutually exclusive snippets of code.

Snippet 1:
template<typename T>
struct something { int a; };
template<typename T>
struct something<const T> { double a; };

Snippet 2:
void func(const std::vector<const Box>& box);
int main() {
  func(std::vector<Box>());
}

Currently, snippet 1 is valid C++, while snippet 2 is not. Answer honestly now: are you guys happy that this is the case? Do you think this is a good way for a declaration called 'const' to work? Because I sure as hell don't. I consider this a fundamental problem with the definition of const.

I'm trying to propose a system which would fix this problem. If const behaved as I've been trying to describe, then snippet 2 would be valid, and snippet 1 would not.

So why am I getting such hostile responses? Is it because I started by saying 'const is broken', and everyone took it literally, thinking I didn't understand how it works? Is it because you think my definition of const is somehow internally inconsistent? Or is it just because you truly like the current behaviour (keeping in mind that it allows snippet 1 and not snippet 2)?

I'd like to explore the idea of a propagating const, rather than a type qualifier that creates distinct types. This would allow snippet 2 to work instead of snippet 1. If you have real arguments about why it's a bad idea, then by all means, share them. But if you still think I don't understand how const works, or if you like the fact that snippet 1 is possible and not snippet 2, well I'm not sure how we can continue this discussion.

At least compile it properly:

gcc -x c -std=c99 -v -Q -pipe -pass-exit-codes -pedantic -Wall -Wextra -Wfatal-errors -g3 -o test test.c

>>31
Without -O you're missing a number of possible errors.

>>32

Optimization will mess up with the debugging information embedding (-g3 in this case) and [i]could/i] mess up the purpose (or output) of your program.

>>10
If you want a pointer to const you should man up and actually use a pointer to const. Quit bitching that a const pointer doesn't do what you want.

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

>>35
technically-incompatible struct
Uh casting solves incompatibility.
Try it.
blah.c:18: error: assignment of read-only location ‘*mybox->numbers’

But you know what? None of this even matters. Nobody abuses const. It just doesn't happen. I wish you'd pick something people actually cause problems with to complain about.

>>36
Post your code.

And since you don't have to cast anything to pass a pointer to non-const into a function that expects something with const in it, so your suggestion of casting is pretty weak.

You're right though; >>10 is still a fgt.

>>36
Nobody abuses const
wat

>>37

typedef struct { int *numbers; } box;
typedef struct { const int *numbers; } box_consts;
Allocate a box, accept a box_consts. You can figure out the rest. You can also provide the struct anonymously in the function. If you don't want to cast, try using onion.

(Of course none of this is practical.)

>>38
When was the last time someone accepted your const data and then mangled data it referred to in an unexpected manner? I'm guessing never. People who write APIs like that don't acquire many users. People who write code like that don't collect many paycheques.

STD::MY_ANUS