this post was submitted on 02 Nov 2023
1407 points (98.6% liked)
Programmer Humor
32410 readers
465 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
It happened because the programmer changed the API from a call that accepted integer values between 0 and 32767 (minimum and maximum wheel speeds) to one that accepted float values between 0.0 and 1.0. A very reasonable change to make, but he quick-fixed all the compiler errors that this produced by casting the passed integer parameters all through his code to float and then clamping the values between 0.0 and 1.0. The result was that formerly low-speed parameters (like 5000 and 6000, for example, which should have produced something like a 20 mph ball with topspin) were instead cast and clamped to 1.0 - maximum speed on both throwing wheels and the aforesaid 125 mph knuckleball. He rewrote his tests to check that passed params were indeed between 0.0 and 1.0, which was pointless since all input was clamped to that range anyway. And there was no way to really test for a "dangerous" throw anyway since the machine was required to be capable of this sort of thing if that's what the coach using it wanted.
This would cause alarm bells to ring in my head for sure. If I did something like that I would make a new type that was definitely not implicitly castable to or from the old type. Definitely not a raw integer or float type.
That kind of code usually is written on a restricted dialect of C.
C is not a language that allows for that kind of safety practice even on the fully-featured version.
Even in C this is possible. Just wrap the float or whatever in a struct and all implicit conversions will be gone.