> I take it you've never seen a program written for a cell phone, a 
> set-top box, or an MP3 player?

No.

I have also never seen a program written to control a nuclear reactor. 
I'm guessing that for such a program, machine efficiency is irrelevant 
(if we need a faster PC, we'll just buy one), and program correctness is 
the *only* criteria of any significance. I bet people writing such 
software don't just accept random hangups and crashes as an unavoidable 
fact of life. They fix them. All of them.

Anyway, embedded programming and safety-critical programming are both 
very specialist. I doubt many people will ever see such code in their 
lives. And I guess you could argue that games programming is pretty 
specialist too... "Most" programs, after all, are either desktop 
applications or web applications, and most of them just push data around.

Post a reply to this message

Sabrina Kilian wrote:

> It looked like the problem was that the voidp was being free()ed in the
> event handler, and the data they wanted to pass into the event handler
> was something that couldn't/shouldn't be sent to free(). Maybe copying
> that data out to a malloc block would have taken too much time, since it
> was for controller inputs.

The way I read it, they had a structure with two integers and a void 
pointer. "But we couldn't just add an extra integer field, because we'd 
have to change a few thousand other functions." I'm not seeing why 
changing a structure to have a new field which is only used in certain 
places is a problem.

Then again, we're talking about a large, complex codebase. Maybe there's 
something relevant they forgot to mention or something...

Post a reply to this message

> No, what I'm saying is "if adding debug code alters all the bugs, how 
> does that not make it scientifically impossible to remove all the bugs?"

It's virtually impossible to remove them all anyway (heck, you won't 
even /notice/ some of the bugs).

And of course one develops an instinct where such Heisenbugs /really/ 
originate.

It's also the type of bugs where doing a long weekend (or sometimes a 
long week) of "extreme debugging" will usually get you somewhere.

The worse problems are those where the error mechanism is plain obvious, 
but is inherent in the software design, and fixing it invariably creates 
a bug somewhere else, which can only be fixed by introducing a third 
one, which in turn can only be fixed by re-introducing the first one... 
seen such things happening; with such bugs "oscillating" for a month or 
so before people decided to get back to the drawing board, and redesign 
that part of the application. That was an embedded system - in a large 
software project for an insurance company I was briefly involved in, 
some bugs had allegedly been oscillating between "fixed" and "broken" 
for years already.

Fortunately that kind of bugs doesn't suit my working mode: Repetitive 
tasks - i.e. anything I encounter more than once - typically prompt me 
to invest a lot of time and energy into making sure I never have to 
spend any significant time on them a third or even fourth time.

Post a reply to this message

>> No, what I'm saying is "if adding debug code alters all the bugs, how 
>> does that not make it scientifically impossible to remove all the bugs?"
> 
> It's virtually impossible to remove them all anyway (heck, you won't 
> even /notice/ some of the bugs).

Sure. But if you know there's a bug there, but it vanishes every time 
you try to fix it, then even though you know it's there, it must surely 
be impossible to actually fix.

> And of course one develops an instinct where such Heisenbugs /really/ 
> originate.

Well, yeah, there is that. If you don't *do* crazy stuff with pointer 
arithmetic in the first place, you're less likely to have problems.

> The worse problems are those where the error mechanism is plain obvious, 
> but is inherent in the software design, and fixing it invariably creates 
> a bug somewhere else, which can only be fixed by introducing a third 
> one, which in turn can only be fixed by re-introducing the first one... 

In other words, the design of your application doesn't let you solve the 
problem properly, and the only way to get it to work is with a hack that 
doesn't work properly, which then introduces more problems that can only 
be fixed with hacks... until eventually you figure out that it's less 
work to redesign your application to work right in the first place.

[Can you tell how many large programs I've worked on?]

Post a reply to this message

Invisible schrieb:
> I have also never seen a program written to control a nuclear reactor. 
> I'm guessing that for such a program, machine efficiency is irrelevant 
> (if we need a faster PC, we'll just buy one), and program correctness is 
> the *only* criteria of any significance. I bet people writing such 
> software don't just accept random hangups and crashes as an unavoidable 
> fact of life. They fix them. All of them.

No. *Those* people make sure random hangups and crashes *never ever* 
happen in the first place.

Well, at least I hope so...

Then again, nuclear reactors are designed in such a way that they don't 
necessarily need a computer at all.

Post a reply to this message

Invisible schrieb:
> The way I read it, they had a structure with two integers and a void 
> pointer. "But we couldn't just add an extra integer field, because we'd 
> have to change a few thousand other functions." I'm not seeing why 
> changing a structure to have a new field which is only used in certain 
> places is a problem.

It wasn't a structure: It was a callback function signature.

That is, there was some module to dispatch events; other modules would 
ask this dispatcher module to call particular functions, as in "if a 
controller button press comes in, please call me back; my address is XYZ".

Of course the dispatcher function would have to know what parameters to 
pass to the function stored at address XYZ. For this purpose, all such 
callback functions would conform to the same set of parameters - in this 
case two integers and a pointer.

Something along these lines.

Post a reply to this message

Invisible schrieb:
> Well, yeah, there is that. If you don't *do* crazy stuff with pointer 
> arithmetic in the first place, you're less likely to have problems.

"Less likely" hits the nail straight on the head, in every sense.

> In other words, the design of your application doesn't let you solve the 
> problem properly, and the only way to get it to work is with a hack that 
> doesn't work properly, which then introduces more problems that can only 
> be fixed with hacks... until eventually you figure out that it's less 
> work to redesign your application to work right in the first place.

Exactly! Except that typically some other bloke did the original design, 
has already left the company, and first thing you need to figure out is 
whether there was any reason he chose that braindead approach...

> [Can you tell how many large programs I've worked on?]

 From what statements I read from you so far, I'd guess they amount to 
something like, roughly, let me think, about.. um - zero?? ;-)

Post a reply to this message

clipka wrote:
> Invisible schrieb:
>> The way I read it, they had a structure with two integers and a void 
>> pointer. "But we couldn't just add an extra integer field, because 
>> we'd have to change a few thousand other functions." I'm not seeing 
>> why changing a structure to have a new field which is only used in 
>> certain places is a problem.
> 
> It wasn't a structure: It was a callback function signature.

Oh, right. I thought it was a C struct.

If you're got to actually change function prototypes then, yeah, that's 
not going to happen...

Post a reply to this message

Invisible wrote:
> No, what I'm saying is "if adding debug code alters all the bugs, how 
> does that not make it scientifically impossible to remove all the bugs?"

Code inspection. You know as well as the computer does what the computer is 
doing, so you can sit and pay lots and lots of attention to the problematic 
code and figure out exactly what's going on.

Which is what amazes me about medical progress, where you *don't* know 
exactly what's going on, but people manage to figure out (for example) what 
DNA replication actually *looks* like, and how fast it goes, and etc.

-- 
   Darren New, San Diego CA, USA (PST)
   Understanding the structure of the universe
    via religion is like understanding the
     structure of computers via Tron.

Post a reply to this message

scott wrote:
> I guess they didn't bother with such things in the iPhone :-)

The bit I like best is where they count the number of bytes they received 
before they turned off the receiver and then adjust the wake-up time they 
program into the hardware, on the basis that the heat from running the 
receiver will have made the crystal run at a different speed for the next 
1.28 seconds they're asleep, and you don't want to wake up too soon or too 
late. :-)  Scary stuff going on inside there.

I also found out that while my car has a bluetooth headset feature built in 
that lets me make hands-free calls from the car without taking the phone out 
of my pocket, lots of cars in Europe use the "SIM profile" of bluetooth. So 
there's an entire phone built into the car that just wirelessly accesses the 
SIM chip, pulling in the phone book of whoever is in the car and everything. 
Very cool.

-- 
   Darren New, San Diego CA, USA (PST)
   Understanding the structure of the universe
    via religion is like understanding the
     structure of computers via Tron.

Post a reply to this message