C word

[SiliconWizard]

You don't need to use that construct if you don't want to.

It was not written by me. That is the point. It was a mistake made by someone who edited the file making a mess without knowing it, and GCC silently accepted it.

Well, as I said, it's a perfectly valid C construct, so of course it'll accept it. It's only a mistake if the assignment is not what was intended (here to initialize both lvalues to 0). It's not a mistake per se.

Again, I agree it's a bit unfortunate, and I gave the potential pitfalls and the probable initial rationale to use it.

And if it's strictly against your rules to use this construct (which I would second), just add a check for that in your static analysis tools.

[legacy]

I have no idea if it's correct or buggy but it's easy to say what it does

Yup. There are similar points in the kernel source and they are correct. But, in the specific case, it was "disabling" a kernel driver like if needed to be "skipped", which then actually made the probe to fail.

Why does it happen? What's wrong? it's a hardware failure? you have to investigate. And this opens doors to the slowest and most tedious ways of finding a bad git commit. You checkout some old commit, make sure the broken code isn't there, then check out a slightly older commit, check again, and repeat over and over until you find the flawed commit.

Code: [Select]

do
{
    branch_back();
    is_ok=does_it_work();
}
while (is_ok isEqualTo False);

Which, in the end, was a stupid mistake: a line of code deleted and appended with the following, which "looks" correct because the C grammar allows A = B = 0 

[Nominal Animal]

Now maybe you're thinking of the abused way of using hungarian notation, and taking it too far, which I don't do. Some abusive users of it have actually gone way too far (I remember Microsoft was a heavy user of it, and went a bit too far with it), and coming up with prefixes for almost every possible type definition, even custom ones! This is not at all what I do. I keep it clean and simple, and this way maintenance is absolutely no issue. I'll prefix pointers with p. If a given identifier is not a pointer, it's not prefixed with p. End of story.

You hit the nail on the head.  Looking at the Wikipedia article, it's the Systems Hungarian I oppose, because I've seen issues with short/int/long and unsigned prefixes (and near/far pointers on code I haven't used but have looked at).
Apps Hungarian looks non-problematic to me.

Your variant, Silicon Hungarian, with just pointers marked for easier human parsing, has nothing objectionable to me.

Some other prefixes that might be useful would be n for counts, s for human-readable strings, and b for binary blobs.  The point is, these act like comments: they help humans parse the programmer intent.  One could claim that that's not the case with pointers, but because * and & are common in expressions, having an additional marker that a variable is a pointer, does help express programmer intent, and probably makes expressions easier to parse correctly for us humans.

[Nominal Animal]

I have no idea if it's correct or buggy but it's easy to say what it does

Yup. There are similar points in the kernel source and they are correct. But, in the specific case, it was "disabling" a kernel driver like if needed to be "skipped", which then actually made the probe to fail.

That's an exact example about what I wrote earlier, about comments and trying to remember without looking up the order of parameters for memset(): even Linux kernel developers make mistakes like that surprisingly often.  Which just shows why expressing developer intent is so important for maintainability and bug-fixability.

(Which is kind of why I feel the same way about Obfuscated C contests as I do about freediving in sewers.)

[SiliconWizard]

(...)
Which, in the end, was a stupid mistake: a line of code deleted and appended with the following, which "looks" correct because the C grammar allows A = B = 0 

Oh, now I get it why you said it was a "mistake". Didn't know it was an accident and not written on purpose...

Well, again, I think this construct should indeed be banned from C, and I guess the std committee has probably raised that many times and never resolved to ban it; that would probably break a lot of legacy code.

The simple rule to add would be that an assignment expression would have no definite type instead of being a rvalue of the type of its lvalue. It could for instance have the "void" type, so such constructs would all be incorrect C in any case.

The example you gave is not the only one, there's also the very famous: "if (a = b)". It's correct C. Was "if (a == b)" meant instead? Who knows... but it's correct C for the same reason: "a = b" is an rvalue! If "a = b" expression was of type void, neither "a = b = c" or "if (a = b)" would compile. End of the story. So here is my proposal for the next std version...

And that said, the "if (a = b)" was so ubiquitous and problem-ridden that most decent C compilers will now give you a warning for that. (Such as: "did you mean a == b ?"), but will give you no warning whatsoever for "a = b = c = ..."