Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×

Comment Re:No disrespect to GCC, but why not LLVM? (Score 1) 78

I'd bet £10 that, in all these cases there was a subtle bug in the code.

For example, in C, shifting a 32 bit value by 32 bits is undefined behaviour. Intuitively, you might expect all of the bits to be shifted out of the number, the same as if you shifted it by one bit thirty two times. However, it is just as likely that nothing at all happens. I guess it is even possible to generate an invalid op code.

Why? On 32 bit Intel, the field in a shift instruction is only five bits wide and you need six bits to represent 32. The compiler could compile a 32 bit shift as a 31 bit shift and a 1 bit shift or mask the shift amount leaving you with a shift of 0 or possibly even put 32 into that field thus setting a bit outside the field.

Weird crashes that go away when you call particular functions or add local variables to a function are almost always caused by stack smashing bugs. For example, you might allocate an array on the stack and then pass a pointer to it in a function call. If the called function assumes the array is bigger than it really is (or is told that), it might write past the end of the array thus destroying something important, like it's own return address. Adding local variables makes a bit of extra padding so writing past the end of the array doesn't do enough damage to crash the program.

Comment Re:Poor Design... (Score 2) 73

It's done the way it is because the alternative is unmanageable.

Apple would have to introduce a way for app developers to add external dependencies to their executables and for those external dependencies to be downloaded, if necessary, along with the app. This is obviously all possible as the Linux and BSD package management systems demonstrate but it would mean Apple would have to maintain an enormous repository of external libraries and the app developers would have to regression test their apps against every single version of the library just in case downloading a new version breaks their app.

Comment Re:It depends (Score 1) 486

You didn't read their paper properly. They make exactly the point that you are making. i.e. that "writing to disk", in most cases, does not mean physically writing individual bytes to the disk. The abstractions provided by both the language and the operating system help to make the obvious implementation as fast or faster than naive programmer created optimisations. In other words, this is a confirmation of the saying

premature optimisations the root of all evil

There is a WTF in the paper and it is their claim that Python doesn't run in a VM.

Comment Re:This is a great excuse (Score 1) 119

I certainly wouldn't be caught using nano, not since our sys admin accidentally trashed a Linux system by editing the pam config file with nano. After he saved the file, nobody could log in anymore because nano inserted a line feed where a long line had wrapped in his terminal.

We got the system back by booting from a live CD and using vi to join the broken line back together.

Slashdot Top Deals

God help those who do not help themselves. -- Wilson Mizner

Working...