
The Easy Ones – Three Bugs Hiding in the Open - nikbackm
https://randomascii.wordpress.com/2020/08/30/the-easy-ones-three-bugs-hiding-in-the-open/
======
rwmj
> printf(“%d, %f”, f, i); // Swapping float and int – could print nonsense, or
> might actually work (!)

I'm going to guess because the ABI says they are passed in int and floating
point registers, so the actual order they appear doesn't matter?

~~~
brucedawson
Yep. On Windows that code will misbehave when compiled for x86, but will work
"correctly" when compiled for x64, and probably ARM64.

------
jeffrallen
> hiding in plain site

Easy bugs hiding in plain sight, you say?

------
markdog12
> Nobody ever looked at the monitoring dashboard

> The fix was a few lines of code to stop traversing after twenty navigation
> nodes, presumably saving a few million dollars in server and power costs

I wonder if this is Stadia?

EDIT: Whoops, I don't think so:

> needed to move on to a different company

~~~
muststopmyths
Valve, probably, based on his job history.

------
jansan
_> although, really, if you have compiler warnings you need to rethink your
life choices_

Is this a joke, half a joke, or serious?

~~~
ThePadawan
I know what you mean, but I don't share your attitude.

I have worked on codebases where 8000 compiler warnings was just "So no errors
then? That means the build is fine."

But 7990 of those warnings had been there for at least five years. Adding the
8001st warning in your build still meant that you probably did something ill-
advised or poorly thought out.

It's just very hard to allow/forbid the right warnings per compilation unit
(this was in the C#/.NET ecosystem) to tell the compiler what you did or did
not care about.

~~~
brucedawson
Curious. How do you know if you've added the 8001st warning that indicates
that you did something ill-advised? It seems that such a huge warning count
makes it very hard for the compiler to tell you things.

I've generally found it quite practical to get warning counts to zero with
some combination of fixing the issues and disabling warnings that have a poor
signal-to-noise ratio. The one exception was /analyze builds. There I added
filtering so that I could treat some warning types as fatal, and others would
be reported on only when they were new.

~~~
ThePadawan
> Curious. How do you know if you've added the 8001st warning that indicates
> that you did something ill-advised? It seems that such a huge warning count
> makes it very hard for the compiler to tell you things.

Well, doing a clean checkout of the master branch, noting N=number of
warnings, then making your changes and comparing with N. At least that is what
I did. It was not very popular, since no one ever tracked N on master at all.

> I've generally found it quite practical to get warning counts to zero with
> some combination of fixing the issues and disabling warnings that have a
> poor signal-to-noise ratio. The one exception was /analyze builds. There I
> added filtering so that I could treat some warning types as fatal, and
> others would be reported on only when they were new.

I completely agree that this is how it should be done. I vaguely remember that
this is however quite complicated to achieve in the .NET ecosystem. Something
about a library A being called in another project B respecting the disabled
warnings of A when compiling A and B when compiling B, so you as a client
could never disable warnings yourself (?).

This was quite a while ago, and as I didn't work too much on A-type projects
(only B-type projects), investigating it was never my responsibility. I just
got told "It's not that simple" by the A-type employees.

