Terrible idea. If a programmer is so unfamiliar with C/C++ to believe ^ is pow(), she/he will create a lot of other problems regardless. Without to mention the kind of bugs created by such incorrect usage would be simple to spot most of the cases.
Wait... so your point is that since "bad programmers" do this, there shouldn't be a warning for it? That is among the silliest thing I ever heard. Especially since there's a trivial way to get rid of the warning: just write "18" instead of "2^16", if you REALLY intended the xor.
Also: it's incredibly naive to think that "bad programmers" are the only ones that would make a mistake like this. I'm very familiar with all C/C++ operators and know perfectly well that the caret represents xor, but I could easily imagine myself slipping and writing 2^16 instead of 1 << 16, because that's how the rest of the world writes exponentials.
Let he/she who has never written a typo and had the compiler save them cast the first stone.
> Wait... so your point is that since "bad programmers" do this, there shouldn't be a warning for it? That is among the silliest thing I ever heard.
In all honesty while I don't agree with this particular instance, the reasoning isn't ridiculous. If we assume it's true that it'd only affect bad programmers, then you probably wouldn't want to add it, since it'd increase the false positive risk and/or otherwise potentially get in the way of everyone else. (Kind of like how you wouldn't make cars start honking when they're turned on as a means of protecting against bad drivers, even thought that might well save lives.) Some tools just need to assume some base level of expertise to be effective.
You snuck in a second premise to the argument: that it will increase the false positive risk. And if we accept that premise, we don’t need the other one.
Bad programmers are the ones who need the most help from our tools. Saying there’s no need for a warning because only bad programmers will benefit is like saying there’s no need for crossing guards because only stupid children get killed crossing the street.
I think you just helped me understand where the objection comes from. The people against this warning seem to feel infantilized by these type of warnings, much in the way you're comparing it to crossing guards for children. My view, and I guess the view of people arguing for these kind of warnings see them like seatbelts: a mild annoyance that is very much worth it.
Sounds about right. I don’t really get it myself. As a professional C and C++ programmer, every mistake is punished severely by the computer and I want all the help I can get in avoiding them. Warnings aren’t annoying, what’s annoying are one-in-a-thousand crashes that only happen on someone else’s computer.
I would say this seems more like airbags: a safety feature which requires no work on the user's part, 99.999% of the time, and which you might not even know exists up until the point when it jumps into action to save you.
If you want to make the argument "this is a bad warning because it will cause many false positives", then that's a perfectly valid argument to make. It doesn't really apply in this case, but it's a valid argument to make against a warning being added.
That's not the reasoning given. The reasoning given is that since only bad programmers would make this mistake, it shouldn't be a warning at all, since those kinds of programmers "will create a lot of other problems regardless". That is nonsensical. You could make the same argument against ANY warning. The whole point of a warning is to alert the developers that, while their code technically follows the rules of the language, they've probably made a mistake.
Let's way that warnings are very important, they cause noise, so such noise should be deserved for instances that are really common mistakes among the population of programmers that have some clue. There are many errors like the one above that can be made by clueless programmers for which you can't emit a warning at all, like misusing postfixed/prefixed increment operators or alike.
The vast majority of people writing C that I've seen in the past 20 years are occasional C programmers. We write in higher-level languages, and occasionally drop down into C to troubleshoot a library we're using. I haven't been a full-time C programmer since late last century. I see C code these days and think "huh, so that's valid in C now".
I get that you are a full-time C programmer, but unless you're volunteering to take on all my C troubleshooting work, this seems almost punitive. Like building a balcony with no railing, because nobody would just walk off a ledge -- and yet, sadly, professionals still die from falls.
To say that all such people are "clueless", regardless of skill or training or experience, is to fall back on the old test pilot mentality: the good survive, therefore, if you didn't survive, you (retroactively) must not have had The Right Stuff after all.
Joel Spolsky explained the reasoning more eloquently than I could:
"Now, even without going through with this experiment, I can state with some confidence that some of the users will simply fail to complete the task, or will take an extraordinary amount of time doing it. I don’t mean to say that these users are stupid. Quite the contrary, they are probably highly intelligent, or maybe they are accomplished athletes, but vis-à-vis your program, they are just not applying all of their motor skills and brain cells to the usage of your program. You’re only getting about 30% of their attention, so you have to make do with a user who, from inside the computer, does not appear to be playing with a full deck."
I trust myself and the people I work with, but I still wear a hardhat when they're working overhead, and I tie all my tools to my belt when I'm working at height. It's the clueless people who don't learn from the mistakes of the past.
Let me clarify - you're saying that just because we can't catch all programming mistakes means we shouldn't bother catching any, even though this is a pretty solid example of one that would be worthwhile and easy to do?
Nope, I think that to catch trivial errors like that is mostly unhelpful, what bothers me about that is that could emit a warning in perfectly ok code, for instance as a result of a post-processing that maps symbols to literal values. Given that 3^5 will never be the result of some programing genuine mistake, but means not knowing the language, I think it is worse to create issues to people that know what they are doing (emitting a useless warning), than trying to advice people not knowing the basic of the language. Anyway such mistake will be realized very soon by the inexperienced programmer.
At first it was my knee-jerk reaction as well but it's bit dumb frankly. I write some python semi-regularly and even though I'm familiar with its syntax I commonly end up putting ; at the end of statements (which generally doesn't do anything for better or worse) and use && and || instead of 'and' and 'or', mainly out of muscle memory.
I can imagine a casual C coder could easily end up using ^ as "pow" for very much the same reason if they're used to it working that way in other languages. On top of that the proposed warning has extremely low chances of triggering on a false positive on actually legit code. I think it's a good proposal.
>Without to mention the kind of bugs created by such incorrect usage would be simple to spot most of the cases.
That's not obvious to me at all. Bogus bitfield values could be rather tricky to track down, especially since they might work correctly "by chance" in simple cases (for instance even if the value of the constant is completely wrong, as long as it's != 0 you can set it with |= and test it with & and it'll appear to work mostly correctly).
I think you're being unrealistic about development in a team with mixed experience levels. These things slip through. We can stop them automatically, without needing to rely on a manually written test, or on being spotted in a code review. It's all upside from where I'm standing.
Experienced people make mistakes, and that's okay. I've made mistakes like this, or worse. I want my tools to help me write good code, not assume that I'm an infallible machine.
We need to kill the myth that good programmers don't need help from their tools.
Incremental learning and guidance is important. If the compiler can point out something that's technically correct but in practice wrong (because 2^16 is the weirdest way of writing that value) it will help some people
My take is that for those who are trying to be as pedantic as using -Werror flags would have a lot of fun putting up pragmas to remove the the false positive.
I agree with you, but this thread is full of people thinking it's a good idea because they or their colleagues are prone to that kind of silliness. For people who write C or C++ every day it's stupid compiler second-guessing, and it can also create issues for generated code, but this thread shows that our tools may need adjustment to better deal with today's level of incompetence.
