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

Invisible wrote:
> software don't just accept random hangups and crashes as an unavoidable 
> fact of life. They fix them. All of them.

*Probably*, yes.

It's not a matter of "unavoidable fact of life". It's simply a cost to 
benefit ratio. If over the lifetime of your computer you spend (say) six 
hours waiting for it to reboot, or you could spend 60 hours finding and 
fixing the bug that's causing that problem, what do you do?

> Anyway, embedded programming and safety-critical programming are both 
> very specialist.

Not especially, no. Indeed, I bet if you go around your house, you'll find 
you have more embedded applications in your house than you have desktop 
applications.  (Don't forget to count the BIOS, the NIC card, the sound 
card, etc in your PC. ;-)

> I doubt many people will ever see such code in their 
> lives.

Sure. And few people will start their own companies. That doesn't mean 
business law is a specialized endeavor.

 > And I guess you could argue that games programming is pretty
> specialist too... 

I would say so, yes.

> "Most" programs, after all, are either desktop 
> applications or web applications, and most of them just push data around.

Hard to say, really. Certainly the *easy* programs are desktop and web apps.

-- 
   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

Invisible wrote:
> The way I read it, they had a structure with two integers and a void 
> pointer.

It says "each event was passed around with two integer arguments and a void 
pointer in case you needed extra parameters."

I guess you could read that as an event being an object or structure. I read 
it as an event being a function call with three arguments. I see now that it 
is pretty ambiguous.

Either way, the right answer was to add the extra field if they needed it. 
It's hard to understand how that would be difficult, with the compiler 
catching the mistakes for you. Harder to be sure if it's an allocated 
structure passed around rather than function arguments, for sure.

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

If it's passed around as arguments, you first have to track down all the 
functions that are "event" functions and add the new argument, then pass 
that argument from caller event functions to callee event functions if 
events can call other events. The compiler will help here. (Indeed, you can 
just add the extra argument, and compile, and fix the 
wrong-number-of-arguments error and compile, and etc, working your way up 
the call chain.) Falls apart if you're doing something to queue events for 
later or some such, and the function doing the queuing fails to queue the 
new argument that the function dequeuing needs. That's a bit harder to track 
down.

If it's a structure, you have to make sure you allocate and free the right 
amount of memory, which could certainly be a problem if you're silly enough 
to hard-code the size of the structure (or assumptions about the size) 
anywhere. For example, if you have a big queue of events, and you need 1000 
of them to fit in 8K of memory, and they're 8 bytes each, adding another 2 
bytes to each is going to push you over the limit.

Impossible to say without more info.

-- 
   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

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

Not sure why not. It's actually pretty easy.

You fix the routine that needs the new parameter, and the routine that has 
the new parameter. You compile the code. Anyone who calls the new routine 
won't compile. Fix them to accept a new parameter and pass it in. Iterate 
until all functions on the call chain between where you have the parameter 
and where you need the parameter are passing it down.

-- 
   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

On 24-8-2009 18:09, Darren New wrote:
> 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.
> 
I like that. Nice idea for our cab-driver when he has to transport 
another celebrity.

Post a reply to this message

andrel schrieb:
>> 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.
>>
> I like that. Nice idea for our cab-driver when he has to transport 
> another celebrity.

Yes, that *could* be a security problem :-)

It's not as bad though as one might think: Virtually all phones out 
there won't allow a phonebook download without proper bonding, nor allow 
proper bonding without user interaction. So unless the celebrity is 
really stupid...

... wait - what?! :-P


(BTW, I actually did work on things like those.)

Post a reply to this message

Darren New schrieb:
> It's not a matter of "unavoidable fact of life". It's simply a cost to 
> benefit ratio. If over the lifetime of your computer you spend (say) six 
> hours waiting for it to reboot, or you could spend 60 hours finding and 
> fixing the bug that's causing that problem, what do you do?

Well, if that's a total of six man-hours (as opposed to maybe thousands 
of people losing six hours each), then it's more economic to leave the 
bug in there. Provided it doesn't cause any other harm like destroying 
valuable data, setting off a thermonuclear war or something...

That's one reason why in-house tools tend to be so crappy: It's more 
economic to accept the loss of productivity of the few people who 
actually use it, than investing that productivity into improving it.


> Hard to say, really. Certainly the *easy* programs are desktop and web 
> apps.

I guess old-fashioned mainframe business apps are rather boring, too.

Post a reply to this message