 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New schrieb:
> 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.
Are you *perfectly* sure about this??
This is /not/ something you want to break: Any function you happen to
miss (because it happens to be stored in a void* pointer somewhere, or
whatever, and you happen to be a bit too tired that night) /will/ screw
up your running program in a beautifully obscure fashion. Welcome,
Heisenbug!
Misusing the compiler for identifying stuff affected by code refactoring
is a risky business.
(Other question is, how long does it take to compile? And how many
layers of functions do you have that you'll need to repair? Let alone
that some part involved may be a library you don't have source code
access to.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> 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.
Sure. ANd when you start getting into "thousands of people", the equation
changes again. Now it's not "how many man hours can we save", but "how many
people won't buy our product because of this bug" vs "how much does the bug
take to fix."
If only 3 people are going to switch from Windows to Linux because of a bug
that costs you 6 hours a year, chances of MS spending a man month to fix it
are slim even if it wastes the time of 1000s of people a year.
>> Hard to say, really. Certainly the *easy* programs are desktop and web
>> apps.
>
> I guess old-fashioned mainframe business apps are rather boring, too.
Yup. "Say, generate for me a list of all employees in order of the total
number of days they've worked since getting hired."
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Darren New schrieb:
>> 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.
>
> Are you *perfectly* sure about this??
>
> This is /not/ something you want to break: Any function you happen to
> miss (because it happens to be stored in a void* pointer somewhere, or
> whatever, and you happen to be a bit too tired that night)
Functions don't get stored in void pointers. (I know what you mean.
Understand my point before you complain I missed yours. :-)
If you're complaining that the weak typing of C can fk you up, then sure, of
course. But then, storing an integer into a void* and hoping none of your
code ever follows that "pointer" is at least as bad if not worse. At least
you can't do math on function pointers.
> Misusing the compiler for identifying stuff affected by code refactoring
> is a risky business.
Sure. Of course there needs to be a modicum of intelligence applied to the
parts of the code where the compiler can't tell what function it's calling.
> (Other question is, how long does it take to compile? And how many
> layers of functions do you have that you'll need to repair?
I wasn't meaning to imply you should be mindlessly mechanical about it. Just
that the fact there were thousands of functions to fix didn't mean it was
more difficult than tedious to fix them.
> Let alone
> that some part involved may be a library you don't have source code
> access to.)
That's always a potential problem, yes.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New schrieb:
> Sure. ANd when you start getting into "thousands of people", the
> equation changes again. Now it's not "how many man hours can we save",
> but "how many people won't buy our product because of this bug" vs "how
> much does the bug take to fix."
Absolutely. I just didn't want to go /that/ deep into detail ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
