Hacker News Reader

Hacker News

Comment by ChrisRR | Hacker News Reader

Full thread

ChrisRR

For those who aren't C/C++ programmers, the issue here is people using ^ to mean power where it means XOR in C/C++.

View on HN

Even if it meant power, it would make sense to warn here, because storing 2^16 in an unsigned short yields 0 :-)

these are signed, so you‘re getting -2^16... so many warnings to emit!

/edit: had that mixed up in my head. Interestingly, clang does warn about the overflow:

    main.c:6:17: warning: implicit conversion from 'int'
      to 'int16_t' (aka 'short') changes value from
      65536 to 0 [-Wconstant-conversion]
  int16_t s16 = 65536;

Oops, you meant -2^15 I guess.

No, they meant -2^16, ie, -(0)

-2^16 is not -0. The unary minus binds more tightly than the binary xor, so this comes out as

  -2^16 = (-2) ^ 16 = 0b111...1110 ^ 0b10000 = 0b111...11011110 = -18

if I'm not mistaken.

No, we mean the power operator, 2 to the power of 16 would be '0' in a short int, since the value overflows...

But since philosophically a signed int has '1's in every bit from the MSB to infinity towards the left, it should thus be -0 not 0.

In two's complement (the usual binary representation of signed ints), -0 is the same as 0.

Yeah my own first reaction was “Oh, gcc doesn’t warn about overflow assignment? That’s a definite bug.”

I code in C/C++ too, although not exclusively. I facepalmed a few seconds later, but it goes to show the value of having this be a compiler warning.

I am not a C programmer but my opinion with any language is don’t try to catch mistakes like this in the compiler. Instead leave to configurable and competing linters for people who want to catch possible mistakes like this. Anyone caught by this mistake probably hasn’t tested their program adequately. Any mistake induced by the wrong constant number should be easy to weed out with unit testing.

By the time you write a linter, you've done more than half of the work of a compiler, at which point you might as well just ship it as a compiler. It's a bit different for clang, which is modular and provides libraries that tool writers can use, but gcc is intentionally monolithic.

> By the time you write a linter, you've done more than half of the work of a compiler, at which point you might as well just ship it as a compiler.

Does depend on what kind of lint you want to catch but something like this 'just' needs some lexing and parsing to give a usable AST that's reasonably clean so it's not too hard to write lint rules against it. (Not trivial for C & C++ hence 'just')

Building the full compiler is much more work, especially if you want a decent optimizing compiler.

The back end is a lot of work, but so is the front end in a language like C++.

In fact most of the essential complexity is in the front end; you make do with a simple back end, but the front end is irreducibly complex if you want it to actually compile the language to spec.

And you need the front end to lint, especially if you want to avoid false positives, the bane of linting tools.

And better hope you didn't put in any bugs that GCC does or doesn't have, then you're left helpless as linter and compiler engage in epic battle on who is right.

It's not just nontrivial for C++, you need a full template engine just to properly parse it [1]. Same thing for languages with a lisp-like macro system. Or languages that allow dynamic redefinition od symbols [2].

[1] http://blog.reverberate.org/2013/08/parsing-c-is-literally-u...

[2] https://www.perlmonks.org/?node_id=663393

Unit tests will not catch all issues, the person that writes the unit test will probably not see a corner case when implementing the code so it won't add the test for that corner case in the unit test either.

Or if the same person is writing the test as the code it is testing, given this is a syntax error rather than a logic error, it is likely that the test will be flawed similarly.

A test passing just means that the code and the test agree, not necessarily that both are correct.

Not including a linter in the earlier C compilers are one of the hughe mistakes of that area. Compilers absolutely should have linters, they are very valuable tools. Think about all the common security mistakes in your average C application that could have been avoided over the years with a linter.

I'm pretty sure Dennis Ritchie at some point himself said that not including a linter was a mistake, but I cannot find a quote of this with a quick search.

Back in the day most people actually ignored the few warnings compilers would give them, i do not think that having a linter would be used much (and AFAIK there were some).

"Back in the day?" Check out your system's log file for a scary collection of horror shows. Or compile most packages these days.

In defense: configuring a package that is compiled by lots of people on lots of machines with lots of versions of various compilers requires a lot of attention to warning flags and such. If you aren't starting out a package from a blank buffer it's very hard to get this right.

But I am frequently shocked by the number of compiler warnings I get from code downloaded from public repos and compiled in precisely the environments it's been documented to have been tested on.

He at least said that it was a requirement for the buggy code he saw being written.

"To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions."

-- https://www.bell-labs.com/usr/dmr/www/chist.html

By that logic you could get rid of a lot of warnings. TBH, I think getting good warnings is a major feature of modern compilers.

The kind of developers who are likely to make this mistake are probably not the kind of developers who will use advanced tools including linters or likely doing unit testing.

Some may even have released code that still has these time bombs waiting to occur.

lint was developed in 1979 (https://www.bell-labs.com/usr/dmr/www/chist.html) and we had to wait until clang for many developers start caring about actually using static analyzers.

Every external tool is a lost opportunity for quality enforcement.

Static analyzers existed long before the clang compiler. SAL from Microsoft is used extensively in every codebase I’ve worked with in Windows and it’s amazing, even if you have to get used to macros on all your functions’ parameters.

https://docs.microsoft.com/en-us/visualstudio/code-quality/u...

Surely, and I appreciate its existence.

Just making the point that they have been largely ignored.

That is not a fair assertion. You might have ignored static analyzers until you've discovered clang, but that observation is not generalizable. As others have already pointed out, lint has been used extensively for decades.

I have been using static analysers since the mid-90's.

Ever heard of PC Lint from Gimpel? It was my first one.

Or do you think I would be critic of how many use C, without adopting best practices myself?

One learns a lot about code quality, or lack thereof, when doing enterprise consulting.

> One learns a lot about code quality, or lack thereof, when doing enterprise consulting.

Pure truth, there. One has seen neither really awful code nor really great code until they have seen the wide array of code quality produced by an enterprise with a few decades of software development history. Any enterprise will suffice, it doesn't have to be a huge corporate entity.

There are a very few developers who are really good and who really care, and there are very few who really do not care and who are really not good, and most are somewhere in between.

As addendum to my reply, here are the answer to JetBrains questionnaire about the C++ eco-system among their customers.

Check "Which of the following tools do you or your team use for guideline enforcement or other code quality/analysis?" results.

https://www.jetbrains.com/lp/devecosystem-2019/cpp/

GNU's C linter is GCC warnings. For C, making a linter isn't a big deal, but for C++ writing a robust C++ parser is so hard that the linter will need to use the compiler's parser anyways.

Well, that isn't the only bug in the code, just the one which is being requested for prompting the warning. It's been about a decade since I've written significant C/C++ code, but something far more dangerous stood out to me:

Upon first reading, I'd assume they are seeing the maximum unsigned values, but their variables aren't declared as unsigned -- and C/C++ default to signed values. Secondly, representing the nth power of two actually takes n+1 binary digits, so e.g. 28 is a one, followed by 8 zeros -- overflowing any 8-bit variable, signed or unsigned! This is undefined behavior as-declared (signed values), but would be entered as a zero for explicitly declared unsigned variables.

Personally, if I were to be implementing this, I'd use bitwise operations to generate the correct values, and explicitly acknowledge in a comment something like "the following code knowingly breaks the abstraction of numeric values. It is likely not portable to other hardware, nor should you assume easy extension to other variable types. Das Quellcode ist nicht fur der gefingerpoken!"

And Java, Python, Javascript, Ruby. The list goes on. It's more of a general problem for non-programmers than specifically people who are new to C (unlike the j++ in python someone mentioned).

I am a C++ programmer and yet I also failed to catch on that ^ in the ticket was xor not pow until I read the comments. All it took was being a bit sleepy.

A rather unfortunate operator choice on the part of C: open to confusion and precluded adding ^ as an exponentiation operator to the language.

Reply on news.ycombinator.com