5 ms·

My First Production Bug

53 points by niborgen 2y ago

inglor_cz 2y ago
"Avoid #defines for constants like the plague. Use static constexpr instead." Pretty much every C textbook I can think of now is full of #defines for constants. I, too, am (de)formed by this.
- niborgen 2y ago
  Thanks for your comment. The blog post was written with C++ in mind, but I just learned that C now also has constexpr: https://en.cppreference.com/w/c/language/constexpr https://en.cppreference.com/w/c/language/constexpr. Time to update those books (:
- sltkr 2y ago
  Because `constexpr` was not supported in C until very recently (C23). And `static const` by itself is not a good alternative, because constants can't be used in a lot of places, for example when declaring the size of an array.
  - nj5rq 2y ago
    Constants can be used for array sizes since a lot of C standards ago, right?
    - PhilipRoman 2y ago
      They end up as a VLA which may or may not be what you want.
egl2021 2y ago
I'm working on a code base with lots of #define. I replace them when I'm doing maintenance nearby, but you can't change them blindly: some bit of code may be inadvertently depending on the 0-artifact or something similar. "Science progresses one funeral at a time."
- niborgen 2y ago
  Totally. Luckily, these #defines are often easy to grep for.
sltkr 2y ago
Although using constexpr over #define wherever possible is good advice (and similarly with functions over macros), you can also argue that the culprit is really this snippet: float ts = 1 / FRAMERATE; This blindly assumes that FRAMERATE is a floating-point constant, but there is no reason to assume it is; in theory, other parts of the code could depend on FRAMERATE being integral. The code should be written in a way that ensures conversion to float happens before division, for example: float ts = 1.0f / FRAMERATE;
- tialaramex 2y ago
  In a better language this mistake can't happen anyway. One of the things which too often gets missed when explaining why C++ is unsafe is that it's full of these unnecessary footguns, there is no need to be able to get this wrong. C++ gets this wrong for maximum drop-in compatibility with C, the classic "New Jersey Style" programming language where simplicity of implementation is prized over simplicity of use or correctness.
  - prerok 2y ago
    Define "better language". The duck typed languages all suffer the same problem. Even in Go we had a stupid problem where default json deserializer creates floats (when deserialized into any) and the number was high enough int64 where it lost precision. I mean, we can go at it all night long what pitfalls await in what language. Perhaps Rust is safest with its own pitfalls where you just can't do it safely (looking at you BST and use of Arc). Programming is full of such traps and only inexperienced engineers in a language would make such a mistake. This includes engineers with 20+ years of 1 year experience.
    - jononor 2y ago
      Python (3) gets this right. Integer division is a separate operator: // vs /.
    - jshier 2y ago
      In this case, a language that doesn't support automatic numeric type conversions. For instance, in Swift, 1 / FRAMERATE would give you integer division if FRAMERATE was an Int, or Double/Float division if FRAMERATE was a float, as the 1 literal would be inferred to a compatible type for / if one existed. You would never see Int / Float, or an implicit conversion between numeric types.
nj5rq 2y ago
The last code block has a typo: #define FRAMERATE = 100.0 Should probably be: #define FRAMERATE 100.0
- niborgen 2y ago
  Right, sorry! Corrected now.
  - sdefinit 2y ago
    > Turns out, all the ‘update’ quantities were zero, resulting in the sluggish behavior of the filter. I think you also meant the predict quantities were zero, not the update!
    - niborgen 2y ago
      The prediction quantities were indeed zero, as they get discretized by multiplying with the sampling time. You're right that some discretized part of the update quantities were also zero, resulting in an identity 'A' matrix. I'll correct it, thanks!
irjustin 2y ago
> It took me an embarassingly long time to figure it out Granted it was 2013, don't sweat yourself. The code reads correct, compiles just fine, and it runs! No clear error to hone in on. These are some of the most difficult bugs with the "omg that's so dumb" response out the otherside. When everything appears correct, stepping through the data can take a long time because we know something is wrong but don't know which layer it's at.
- niborgen 2y ago
  > Granted it was 2013, don't sweat yourself. Don't worry, I don't. Funnily, recently something very similar happened. At work, there was this C++ class that had a 'void reset()' member function. Of course, at some point it was used with std::unique_ptr and we got some SIGSEGV. Took me a while to figure out that the '.reset()' was called instead of the '->reset()'. I think these 'omg that's so dumb' bugs are just part of programming.
jojobas 2y ago
[flagged]
- dang 2y ago
  Can you please not be nasty on HN? This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
deleted 2y ago
[deleted]
voidUpdate 2y ago
I keep getting hit by this in C#, where int / int = int. So if I'm trying to calculate the aspect ratio of an image (which has been coming up a lot recently), I cant just do width/height, I've got to cast one of them to a float first, because int / float = float
jbverschoor 2y ago
Biggest problem: "The year was 2013 and I was smack in the middle of my master’s degree. Coding-wise, we were taught Fortran95 and not much else"
- niborgen 2y ago
  Out of curiosity: were you taught how to program properly in university? I'm grappling with the question if colleges should, or if it should be left to 'the school of life'. I'm grateful for the more theoretical courses that I attended instead.
  - jbverschoor 2y ago
    I learned programming by myself using magazines, borland documentation, x2oulu.fi, win95 api book, bao 3d games programming, and reading the java api. The fastest growth I experienced was while working at an internet startup around '00. I only recently got a CS degree just to check off the box. I enjoyed it, and I thought the material was pretty good. Some things were explained very well, other things could've been better, but overall the theory side and some algorithms were pretty ok. On the programming side... Let's just say I'd rather hire anyone (a teenager, or 60 year old) who enjoys writing code than someone with just a CS degree and no ack for programming. College, imo, is the wrong vehicle for knowledge transfer/acquisition for a lot of subjects. University Apprenticeship is the way to go.

53 points by niborgen 2y ago

"Avoid #defines for constants like the plague. Use static constexpr instead." Pretty much every C textbook I can think of now is full of #defines for constants. I, too, am (de)formed by this.

niborgen 2y ago
Thanks for your comment. The blog post was written with C++ in mind, but I just learned that C now also has constexpr: https://en.cppreference.com/w/c/language/constexpr https://en.cppreference.com/w/c/language/constexpr. Time to update those books (:
sltkr 2y ago
Because `constexpr` was not supported in C until very recently (C23). And `static const` by itself is not a good alternative, because constants can't be used in a lot of places, for example when declaring the size of an array.
- nj5rq 2y ago
  Constants can be used for array sizes since a lot of C standards ago, right?
  - PhilipRoman 2y ago
    They end up as a VLA which may or may not be what you want.

egl2021 2y ago

I'm working on a code base with lots of #define. I replace them when I'm doing maintenance nearby, but you can't change them blindly: some bit of code may be inadvertently depending on the 0-artifact or something similar. "Science progresses one funeral at a time."

niborgen 2y ago
Totally. Luckily, these #defines are often easy to grep for.

sltkr 2y ago

Although using constexpr over #define wherever possible is good advice (and similarly with functions over macros), you can also argue that the culprit is really this snippet: float ts = 1 / FRAMERATE; This blindly assumes that FRAMERATE is a floating-point constant, but there is no reason to assume it is; in theory, other parts of the code could depend on FRAMERATE being integral. The code should be written in a way that ensures conversion to float happens before division, for example: float ts = 1.0f / FRAMERATE;

tialaramex 2y ago
In a better language this mistake can't happen anyway. One of the things which too often gets missed when explaining why C++ is unsafe is that it's full of these unnecessary footguns, there is no need to be able to get this wrong. C++ gets this wrong for maximum drop-in compatibility with C, the classic "New Jersey Style" programming language where simplicity of implementation is prized over simplicity of use or correctness.
- prerok 2y ago
  Define "better language". The duck typed languages all suffer the same problem. Even in Go we had a stupid problem where default json deserializer creates floats (when deserialized into any) and the number was high enough int64 where it lost precision. I mean, we can go at it all night long what pitfalls await in what language. Perhaps Rust is safest with its own pitfalls where you just can't do it safely (looking at you BST and use of Arc). Programming is full of such traps and only inexperienced engineers in a language would make such a mistake. This includes engineers with 20+ years of 1 year experience.
  - jononor 2y ago
    Python (3) gets this right. Integer division is a separate operator: // vs /.
  - jshier 2y ago
    In this case, a language that doesn't support automatic numeric type conversions. For instance, in Swift, 1 / FRAMERATE would give you integer division if FRAMERATE was an Int, or Double/Float division if FRAMERATE was a float, as the 1 literal would be inferred to a compatible type for / if one existed. You would never see Int / Float, or an implicit conversion between numeric types.

nj5rq 2y ago

The last code block has a typo: #define FRAMERATE = 100.0 Should probably be: #define FRAMERATE 100.0

niborgen 2y ago
Right, sorry! Corrected now.
- sdefinit 2y ago
  > Turns out, all the ‘update’ quantities were zero, resulting in the sluggish behavior of the filter. I think you also meant the predict quantities were zero, not the update!
  - niborgen 2y ago
    The prediction quantities were indeed zero, as they get discretized by multiplying with the sampling time. You're right that some discretized part of the update quantities were also zero, resulting in an identity 'A' matrix. I'll correct it, thanks!

irjustin 2y ago

> It took me an embarassingly long time to figure it out Granted it was 2013, don't sweat yourself. The code reads correct, compiles just fine, and it runs! No clear error to hone in on. These are some of the most difficult bugs with the "omg that's so dumb" response out the otherside. When everything appears correct, stepping through the data can take a long time because we know something is wrong but don't know which layer it's at.

niborgen 2y ago
> Granted it was 2013, don't sweat yourself. Don't worry, I don't. Funnily, recently something very similar happened. At work, there was this C++ class that had a 'void reset()' member function. Of course, at some point it was used with std::unique_ptr and we got some SIGSEGV. Took me a while to figure out that the '.reset()' was called instead of the '->reset()'. I think these 'omg that's so dumb' bugs are just part of programming.

jojobas 2y ago

[flagged]

dang 2y ago
Can you please not be nasty on HN? This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.

deleted 2y ago

[deleted]

voidUpdate 2y ago

I keep getting hit by this in C#, where int / int = int. So if I'm trying to calculate the aspect ratio of an image (which has been coming up a lot recently), I cant just do width/height, I've got to cast one of them to a float first, because int / float = float

jbverschoor 2y ago

Biggest problem: "The year was 2013 and I was smack in the middle of my master’s degree. Coding-wise, we were taught Fortran95 and not much else"

niborgen 2y ago
Out of curiosity: were you taught how to program properly in university? I'm grappling with the question if colleges should, or if it should be left to 'the school of life'. I'm grateful for the more theoretical courses that I attended instead.
- jbverschoor 2y ago
  I learned programming by myself using magazines, borland documentation, x2oulu.fi, win95 api book, bao 3d games programming, and reading the java api. The fastest growth I experienced was while working at an internet startup around '00. I only recently got a CS degree just to check off the box. I enjoyed it, and I thought the material was pretty good. Some things were explained very well, other things could've been better, but overall the theory side and some algorithms were pretty ok. On the programming side... Let's just say I'd rather hire anyone (a teenager, or 60 year old) who enjoys writing code than someone with just a CS degree and no ack for programming. College, imo, is the wrong vehicle for knowledge transfer/acquisition for a lot of subjects. University Apprenticeship is the way to go.