6 ms·

When your code fails it's never the fault of the language. It's always ones own fault, a typo, some error in the logic, or something. Debugging always reveals t

When your code fails it's never the fault of the language. It's always ones own fault, a typo, some error in the logic, or something. Debugging always reveals that with a stone face. Always. Except > "It turns out, there was a bug in Set.intersection(_:), but it had only been discovered this past June, and the fix hasn’t made it into a public version of Swift yet. "

Avshalom 4y ago
Don't know what to search for to bring it up but there's a story HN used to post occasionally about finding a CPU bug... talk about Always. Except.
davedelong 4y ago
(Hi, I'm the author of the post) It turns out the bug fix has been released publicly, but only on newer OS versions.
- mayoff 4y ago
  Or if you compile in release mode, in which case the fixed version is (maybe only sometimes?) inlined into your executable. I ran into the same bug, but since I'd included a `precondition` to verify that each elf-group had only one common item type, I discovered the bug immediately. I then needed about 5-10 minutes to convince myself that it really was a Swift bug and not a mayoff bug.
frollo 4y ago
Yeah, luckily, those exceptions are really rare. Last time one happened to me I wasted three days before finding the culprit.
smcl 4y ago
As someone who worked on C compilers for DSPs for a few years, I was conditioned for a while to think "compilers are broken, libraries are broken - you have no hope" for a while, when all I dealt with was our software. Obviously that's heavily influenced by what I was actually dealing with day to day and not by normal software development, but still :) One of the guys in my team handled a frantic support request from a Formula 1 team because they required reproducible builds or else they got some fine from the FIA, and they somehow hit a situation where our compiler was outputting different code depending on time of day. Wild.
- nappy-doo 4y ago
  From your description of the bug, I think even know which compiler you worked on. I worked on a competitors compiler. The state of embedded tools in the lates 90s and early 2000s was deplorable. I'm surprised we got anything working. (I went to work for the compiler team because I was so pissed off at how poorly they worked.)
  - smcl 4y ago
    I should maybe have just said, it's not like it's sensitive information. It was @ Analog Devices, and given the engineer who was assigned to this bug I think it would have been for their TigerSHARC DSP. Trying to think who you might have worked for - Green Hills maybe? The compiler itself felt well-written and there were some very smart people involved in developing it. And now that I think about it the bug wasn't different code being output but some value elsewhere in the generated binary itself - maybe some ELF header? I wish I could remember
    - nappy-doo 4y ago
      Ah, I worked at ADI too. I rewrote the TigerSHARC register allocator (not adopted [complicated reasons, but Edinburgh wouldn't accept changes from the US]), and left the DSP group, and soon afterwards ADI. I thought you meant TI. Their compiler would compile in the date of compilation as a string by default (it wasn't deadcode eliminated in the linker because it was sucked in their panic libraries, if memory serves). In any case, yeah, ADI.
hansvm 4y ago
Miscompilations (interpretations) are fairly common in my experience; just most of them don't drastically affect the final result. I used to have a methodical way of investigating most bugs: (1) here's what I know, (2) here's what I don't, (3) here's the thing I would like to know to most restrict the remaining search space. It was fine enough for awhile, but when you don't know things like "I wrote a 0 here, therefore a 0 exists here", or "my code explicitly uses aligned 32-bit reads, so I issued an aligned 32-bit read here", the errors in your assumptions quickly get amplified into nonsense. Nowadays I explicitly includle miscompilation (interpretation), bit-flips, and other such garbage as I write down what I do or don't know about the system, and I throw in ballpark probabilities to figure out where to look next. Most debugging isn't noticably slower that way, but the hairy problems are easily 10x easier when you haven't conditioned yourself to ignore the real solution.
benced 4y ago
For most engineers, you’ll have a handful of times in your career when the compiler or runtime really is the problem. The rest of the time it’s like 95% your fault and 5% the library’s fault.

Avshalom 4y ago

Don't know what to search for to bring it up but there's a story HN used to post occasionally about finding a CPU bug... talk about Always. Except.

davedelong 4y ago

(Hi, I'm the author of the post) It turns out the bug fix has been released publicly, but only on newer OS versions.

mayoff 4y ago
Or if you compile in release mode, in which case the fixed version is (maybe only sometimes?) inlined into your executable. I ran into the same bug, but since I'd included a `precondition` to verify that each elf-group had only one common item type, I discovered the bug immediately. I then needed about 5-10 minutes to convince myself that it really was a Swift bug and not a mayoff bug.

frollo 4y ago

Yeah, luckily, those exceptions are really rare. Last time one happened to me I wasted three days before finding the culprit.

smcl 4y ago

As someone who worked on C compilers for DSPs for a few years, I was conditioned for a while to think "compilers are broken, libraries are broken - you have no hope" for a while, when all I dealt with was our software. Obviously that's heavily influenced by what I was actually dealing with day to day and not by normal software development, but still :) One of the guys in my team handled a frantic support request from a Formula 1 team because they required reproducible builds or else they got some fine from the FIA, and they somehow hit a situation where our compiler was outputting different code depending on time of day. Wild.

nappy-doo 4y ago
From your description of the bug, I think even know which compiler you worked on. I worked on a competitors compiler. The state of embedded tools in the lates 90s and early 2000s was deplorable. I'm surprised we got anything working. (I went to work for the compiler team because I was so pissed off at how poorly they worked.)
- smcl 4y ago
  I should maybe have just said, it's not like it's sensitive information. It was @ Analog Devices, and given the engineer who was assigned to this bug I think it would have been for their TigerSHARC DSP. Trying to think who you might have worked for - Green Hills maybe? The compiler itself felt well-written and there were some very smart people involved in developing it. And now that I think about it the bug wasn't different code being output but some value elsewhere in the generated binary itself - maybe some ELF header? I wish I could remember
  - nappy-doo 4y ago
    Ah, I worked at ADI too. I rewrote the TigerSHARC register allocator (not adopted [complicated reasons, but Edinburgh wouldn't accept changes from the US]), and left the DSP group, and soon afterwards ADI. I thought you meant TI. Their compiler would compile in the date of compilation as a string by default (it wasn't deadcode eliminated in the linker because it was sucked in their panic libraries, if memory serves). In any case, yeah, ADI.

hansvm 4y ago

Miscompilations (interpretations) are fairly common in my experience; just most of them don't drastically affect the final result. I used to have a methodical way of investigating most bugs: (1) here's what I know, (2) here's what I don't, (3) here's the thing I would like to know to most restrict the remaining search space. It was fine enough for awhile, but when you don't know things like "I wrote a 0 here, therefore a 0 exists here", or "my code explicitly uses aligned 32-bit reads, so I issued an aligned 32-bit read here", the errors in your assumptions quickly get amplified into nonsense. Nowadays I explicitly includle miscompilation (interpretation), bit-flips, and other such garbage as I write down what I do or don't know about the system, and I throw in ballpark probabilities to figure out where to look next. Most debugging isn't noticably slower that way, but the hairy problems are easily 10x easier when you haven't conditioned yourself to ignore the real solution.

benced 4y ago

For most engineers, you’ll have a handful of times in your career when the compiler or runtime really is the problem. The rest of the time it’s like 95% your fault and 5% the library’s fault.