81–90 of 280 posts
When I was just getting into the industry, I was offered a job from a team at IBM, working on some OS or other whose name I forgot. I was chatting with the head developer about the workflow. He told me that, as the OS was written in a custom programming language, and the OS was the only program ever written in this programming languages, they found that roughly 50% of the bugs they encountered were in the OS code, an…
Earlier quoted context omitted.
> reckless ... is in the eye of the beholder. They exploit every corner of undefined behavior to the benefit of performance. Indeed other compilers might be "safer." Keep in mind that they also provide you with UBSan to help you detect when you're doing it wrong.
UBSan catches undefined behavior at runtime - so by definition everything it reports was not used by Clang to fold your program to a constant.
I was lead on a project that was making heavy use of the HTML5 filesystem API. We were transiting multiple GB through the API in a single session. The program had a memory leak. It was about the same whether it was deployed through Cordova on iOS or node-webkit on OSX or Windows. There was a _lot_ of code in this thing. A lot of code within the content (which was written by another vendor) and a whole bunch of code i…
This comment has me rather confused. iOS updates webkit at the same time that macOS does; namely, when releasing a major OS update. And they both use the same webkit too. It should not be possible for a webkit bug to be fixed in macOS but still be unfixed in iOS after a major version update (and since you say "wkwebview came" this means there was a major version update).
Earlier quoted context omitted.
clang/llvm makes the gcc developers look like amateurs when it comes to reckless optimizations for that extra percent in the synthetic benchmark. My goto approach for when something breaks in clang but works in gcc is to disable optimization, and when I can narrow it down to a single offending function, that gets optnone slapped on it and done.
> when I can narrow it down to a single offending function, that gets optnone slapped on it and done If you're able to narrow it down that far why not then fix your bug?
Essentially, it was not worth more of my time to figure out how aggressive optimizations were breaking the parts of a memory bandwidth constrained function that aren't worth optimizing in the first place.
For GCC inline assembly means "take your grubby hands off". For clang it's essentially an invitation to do whatever.
I was lead on a project that was making heavy use of the HTML5 filesystem API. We were transiting multiple GB through the API in a single session. The program had a memory leak. It was about the same whether it was deployed through Cordova on iOS or node-webkit on OSX or Windows. There was a _lot_ of code in this thing. A lot of code within the content (which was written by another vendor) and a whole bunch of code i…
This comment has me rather confused. iOS updates webkit at the same time that macOS does; namely, when releasing a major OS update. And they both use the same webkit too. It should not be possible for a webkit bug to be fixed in macOS but still be unfixed in iOS after a major version update (and since you say "wkwebview came" this means there was a major version update).
wkwebview quite possibly brought a major version update, but it sure didn't include the patch we needed. Whether that was because Apple works from a fork that didn't include that patch or the major version was still older than the version we needed, I don't know. There was just no way to get that kind of information out of them.
Earlier quoted context omitted.
clang/llvm makes the gcc developers look like amateurs when it comes to reckless optimizations for that extra percent in the synthetic benchmark. My goto approach for when something breaks in clang but works in gcc is to disable optimization, and when I can narrow it down to a single offending function, that gets optnone slapped on it and done.
> when I can narrow it down to a single offending function, that gets optnone slapped on it and done If you're able to narrow it down that far why not then fix your bug?
"The compiler did not have a bug. The compiler never had a bug. The bug was always in the programmer's code and usually in their understanding of the language... It was caused by a misunderstanding of the way arguments to unprototyped functions were automatically promoted..." - I'd say the bug is neither in the compiler nor in their understanding of the language but in the language itself then. Why on Earth do we nee…
Some people seem to believe that you shouldn't use a language unless you're capable of writing the language yourself.
I was lead on a project that was making heavy use of the HTML5 filesystem API. We were transiting multiple GB through the API in a single session. The program had a memory leak. It was about the same whether it was deployed through Cordova on iOS or node-webkit on OSX or Windows. There was a _lot_ of code in this thing. A lot of code within the content (which was written by another vendor) and a whole bunch of code i…
BTW, what you're talking about isn't a compiler error.
i.e. into the read-only portion of the binary.
The result, of course, was that writing to the variables caused a core dump.
So yes, 99% of the time, stupid programmer errors are stupid programmer errors. But compilers do have bugs.
e.g.
Not a "compiler bug" but a "gosh I wish some people who are working on a project voluntarily that I'm not paying for would do a crap-load of work" bucket: for a while GCC could either compile a program with threads or with exceptions. If you had both threads AND exception code (even if you never threw an exception), the emitted code would eventually crash.