The rotating blade of a chainsaw is an operator accessible area. I guess we need a protector over the entire thing while it's running, cause somebody could touch it.
I don't know how things are where you are, but you need to have a license to buy or rent or take a job operating a chainsaw here. Lesson 1 is that you wear suitable protective clothing. Steel toecapped boots, gauntlets, and eye protectors etc. There's your second level of protection over and above the guards and safety catches of the device itself.
A chainsaw is not a computer, and it has it's own set of standards, which make their own balance of utility against safety.
This world is dangerous, and exercising reasonable precaution, like shutting the machine down, should be expected. If they DON'T do it, then they should run the risk, or mitigate it themselves.
Thanks for your layman's opinion. But your layman's opinion does not and should not override the opinions of the experts that write the standards.
Code fragments, which is what we were actually talking about, are useless without a license to copy them.
I didn't give out simple source fragments, I gave out the source code for two complete games. So yes, they are perfectly usable as they are. Just as much as the story in the parable.
Also, you story assumes a daily, informal interaction and mutual respect and love between the actors.
Exactly. And that's what I want and have with the small community of people that are interested in the platform my games run on.
The parable perfectly fits the topic at hand, because I know exactly what the topic at hand is, and I wrote the parable.
I know exactly what I'm saying here. And yes, the same thing applies to criminal law. A court does not work out if something is right or wrong from first principles each time. It tests what has occurred against a set of written standards - the law.
You misunderstand what synonyms in a dictionary are. Words tend to have multiple definitions, and listed synonyms only mean that there is some overlap, not that the words have all the same meanings.
Grass has a synonym of "Snitch" It also has a synonym of "Marijuana" That doesn't mean Snitch means the same as Marijuana.
In what we have been talking about, a license is not the same as permission. No matter how much you wish they were the same.
The problem is, when does it happen? Was your assert too late and damage is already done? Does it happen immediately after your assert? Heck you're only testing one place in a cached hierarchy, what if it's already inconsistent in other places?
You want a system to localise the error? Look up design by contract, and pre and post conditions. It's all there.
Of course aborting is an acceptable way, but only when things are so bad that context no longer matters. There are severity levels on errors and the vast majority should not abort.
Correct. Lots of reasons for aborting in debug builds, a few reasons for aborting in release builds.
This case is especially egregious as it is a shared library doing input validation and asserting on unexpected input (ignoring for a moment that the input is valid per standard). This is the last thing you want to do in this case - scratch that, it's not even the last thing. The apache example I gave above, doing THE SAME MISTAKE but web facing, is a DOS waiting to happen.
Also correct. No one is trying to defend the assert involved in this particular defect, not asserts in general to validate user input. Real my posts, you'll not see any such thing. At this stage the discussion is about whether there is any place for asserts in release builds. You said there wasn't in your previous post. You have now seen the light and accepted that there is.
Sure Sparky... If you think that is fine, please let me know where you have worked in the last 10 years so I can blacklist those vendors.
You're trying and failing to patronise. I've not been programming for just 10 years, I've been programming since 1979. I do know what I'm talking about. I made a point about asserts having a place in release builds. You tried arguing something else that I didn't say, and in the process you actually accepted my point.
The bagless concept - that is, using a vortex to separate the dirt - was used on our Sears whole house vacuum system back in the late '60s.
That's interesting. I knew they were used for industrial purposes before Dyson, and that's where he got the idea.
But he certainly invented the vortex system for self contained vacuum cleaners. And that was more than simply copying the bigger industrial systems. Details change when the scale changes. Dyson spent a long time developing his vacuum. The proof of that is that he got patents around the world for it, so strong that everyone else had to wait for the patents to expire before they could do any kind of vortex based bagless cleaner.
No one is claiming Apple invented the mouse. But they have invented plenty of other things. Never heard of the Bose thing.
All three are indeed talented at marketing. But that doesn't mean they are not also talented at inventing and engineering. Dyson and Apple are that too. Don't know about Bose.
The balance between functionality and cost of space changed. If anyone is not using asserts for the reason of saving bytes, on anything other than a tiny embedded device, they are severely misguided.
Have you heard of Code Complete? If you're a programmer, you probably should have read it. You should probably have a copy in your bookcase. Go read what it has to say in it's section on Assertions before you post any more ill-informed comments on this thread.
Because on failure assert() calls abort(), which is a good behavior if you're debugging code but is unacceptable for code shipped out to customers.[*]
There are several categories in which it's not only acceptable, it's the best thing you can do. e.g. High security issues, data corruption, or other user harm. Look it up in Code Complete for example.
there are other tools to approach it in release mode: if, switch, exceptions
No. Those can only deal with foreseen errors. They can't deal with unforeseen errors.
[*] Image for a moment that you had patched up apache to assert() whether an URL/URI is valid or not, same as here but web-facing Your webserver's uptime would be measured in seconds.
Checking for a valid URL is a foreseen error, and so shouldn't be an assert. It can be handled reasonably because we've predicted it. That doesn't mean that valid uses for asserts in release code don't exist.
Then instead of an assert you should have a return error (or throw exception) statement.
No. Those can only ever be for foreseen error states. If they are not foreseen, then they are no documentable, and therefore the calling code can take no sensible action to react to the error or exception.
An assert is a documentation of something that's always true and will never fail. If it fails, that's a bug, and there's no graceful handling of bugs - if you could foresee them, you would have already fixed them.
The question is whether to only have them in debug builds or whether to have them in release builds too. Contrary to your ASSERTION, asserts aren't necessarily compiled out of release builds. The answer is they go in release builds too if the worst case scenario is data corruption from continuing in an unpredictable state.
None of this is in Programming 101. This is stuff you learn when you've been programming a long time.
It's general purpose is to give physical form to assumptions in the program itself. It both assures that the assumption *is* always correct past that point, and it documents it.
A novice programmer might say, don't make assumptions. But real programmers make reasonable assumptions all the time. For example if you've just written code to calculate an count, and that calculation can't make a number that's zero or less, then that's a valid assert.
Totally and completely fucking wrong. A well written program should not crash for any reason.
All reasonable length programs have bugs. It's a fact of life.
It should alert the user and allow new input or fail gracefully, not suddenly crash. Asserts should always be compiled out in release code, and cause premature return from the function with an error code or reasonable default, it should NEVER crash on release.
There is no absolute rule on this. It depends on your local coding standards and it depends on the language and platform you're using. There's lots of well written software with release build asserts in it.
Crashing on an assert isn't the worst thing a program can do. Crashing on something that's not an assert is worse, because you don't get the helpful log error that pinpoints the cause. And causing data corruption is far worse still.
I have also had the impression that assert() is a hack that shouldn't be used much (?).
It should be used rather a lot. Every time you believe you know something will always be true, but might break if it wasn't, you should put an assert there.
There's no point putting an IF there, because you can't forsee the case where it will be taken. Likewise an exception - exceptions are for foreseen error states. And ignoring it will result in a harder to find bug if that belief is ever wrong.
It's pretty rare when the bug exists in the assert, rather than the main code. Rarer still when it's an assert that is active in release builds. This is one of those cases. But it doesn't mean that asserts are a bad thing.
Being a programmer is no great claim here. It's almost expected.
And no, it's certainly not a sign of lazy programming. It's the sign of a bug. Everyone creates bugs, not just lazy programmers. And unit testing doesn't approach covering every eventuality. At best it covers easily predicted bugs and regressions.
Bad assumption. You might not intend for the user to type in a null terminated string. But that doesn't mean he can't or won't - depending on the platform. Either because the platform doesn't filter out the ctrl-shift-2 combination, because it's being pasted in, or because it's being piped in.
It has nothing to do with debris; that's just something you made up to justify an obvious over-reach.... Notably missing is durability of the fan blade, a strong hint that it has nothing to do with debris.
Its not made up, it's taken from a presentation on this particular regulation. Sorry if your Google search didn't find it for you. It'll probably take me 10 minutes to find it. If you guarantee me an apology for wasting my time, when I show you, I'll go find it for you.
Durability of the fan is irrelevant, given that we are talking about fault conditions, not normal use. Things break.
Not universally true. Google'sbusiness model is to give away products (search, Android etc.) for free, then get their money from advertisers. You are the product.
For Apple and Blackberry, they make their money from selling you a phone. You are the customer.
This is reflected in the amount of privacy you get with the respective mobile phone platforms.
Just because you don't understand the reason for a reg doesn't mean the reg is unreasonable. It was put there by someone who knows the issue better than you.
In this particular case you're making the same mistake that all the other critics are making. You;re assuming that this is about people putting fingers into the fans rather than what happens when larger fans break and fragment, and there's fly debris.
That's how I know you don't even know what's in the reg, let alone whether it's justified.
It's nothing to do with handing wires, or probing fingers. It's to do with what happens in those rare cases where a fan fragments. And it only applies to fans that are dangerous in this instance, as judged by a formula or density and max-speed.
The inside of a Mac Pro is an operator accessible area, not a service area. It's expected for users to open them. And they should be protected from injury due to manufacturing faults when they do so.
If you want to rely on the idea that the machine is off when the case is opened, then that would require safety cut-off switched that made that happen. Calling people morons doesn't cut it - ordinary people just forget - or have a reason for running it whilst open.
When it comes to safety regs, the potential people that are inconvenienced are manufacturers. The potential people who are benefited are the consumers who aren't killed or injured.
Clearly, in this regard, the regulators (the EU) they are the servants of the people, not the wealthy.
It's certainly not always that way round. But it's a stupid criticism to make in this case.
Slashdot Mirror
Unless you are trying to do Android development in a browser, it certainly has nothing to do with it.
Only the exploitable Java browser plugin is disabled, not Java apps.
Well for one thing, blocking an entire operating system would prevent you from downloading a replacement operating system.
They do actually do something in that direction though. Once iOS is updated to a new version, it can't be downgraded again.
Then his string terminates sooner than the data stream he types. Which won't break anything.
Another bad assumption. Tricks like these are often used in exploits.
The rotating blade of a chainsaw is an operator accessible area. I guess we need a protector over the entire thing while it's running, cause somebody could touch it.
I don't know how things are where you are, but you need to have a license to buy or rent or take a job operating a chainsaw here. Lesson 1 is that you wear suitable protective clothing. Steel toecapped boots, gauntlets, and eye protectors etc. There's your second level of protection over and above the guards and safety catches of the device itself.
A chainsaw is not a computer, and it has it's own set of standards, which make their own balance of utility against safety.
This world is dangerous, and exercising reasonable precaution, like shutting the machine down, should be expected. If they DON'T do it, then they should run the risk, or mitigate it themselves.
Thanks for your layman's opinion. But your layman's opinion does not and should not override the opinions of the experts that write the standards.
Code fragments, which is what we were actually talking about, are useless without a license to copy them.
I didn't give out simple source fragments, I gave out the source code for two complete games. So yes, they are perfectly usable as they are. Just as much as the story in the parable.
Also, you story assumes a daily, informal interaction and mutual respect and love between the actors.
Exactly. And that's what I want and have with the small community of people that are interested in the platform my games run on.
The parable perfectly fits the topic at hand, because I know exactly what the topic at hand is, and I wrote the parable.
I know exactly what I'm saying here. And yes, the same thing applies to criminal law. A court does not work out if something is right or wrong from first principles each time. It tests what has occurred against a set of written standards - the law.
You misunderstand what synonyms in a dictionary are. Words tend to have multiple definitions, and listed synonyms only mean that there is some overlap, not that the words have all the same meanings.
Grass has a synonym of "Snitch"
It also has a synonym of "Marijuana"
That doesn't mean Snitch means the same as Marijuana.
In what we have been talking about, a license is not the same as permission. No matter how much you wish they were the same.
The problem is, when does it happen? Was your assert too late and damage is already done? Does it happen immediately after your assert? Heck you're only testing one place in a cached hierarchy, what if it's already inconsistent in other places?
You want a system to localise the error? Look up design by contract, and pre and post conditions. It's all there.
Of course aborting is an acceptable way, but only when things are so bad that context no longer matters. There are severity levels on errors and the vast majority should not abort.
Correct. Lots of reasons for aborting in debug builds, a few reasons for aborting in release builds.
This case is especially egregious as it is a shared library doing input validation and asserting on unexpected input (ignoring for a moment that the input is valid per standard). This is the last thing you want to do in this case - scratch that, it's not even the last thing. The apache example I gave above, doing THE SAME MISTAKE but web facing, is a DOS waiting to happen.
Also correct. No one is trying to defend the assert involved in this particular defect, not asserts in general to validate user input. Real my posts, you'll not see any such thing. At this stage the discussion is about whether there is any place for asserts in release builds. You said there wasn't in your previous post. You have now seen the light and accepted that there is.
Sure Sparky... If you think that is fine, please let me know where you have worked in the last 10 years so I can blacklist those vendors.
You're trying and failing to patronise. I've not been programming for just 10 years, I've been programming since 1979. I do know what I'm talking about. I made a point about asserts having a place in release builds. You tried arguing something else that I didn't say, and in the process you actually accepted my point.
The bagless concept - that is, using a vortex to separate the dirt - was used on our Sears whole house vacuum system back in the late '60s.
That's interesting. I knew they were used for industrial purposes before Dyson, and that's where he got the idea.
But he certainly invented the vortex system for self contained vacuum cleaners. And that was more than simply copying the bigger industrial systems. Details change when the scale changes. Dyson spent a long time developing his vacuum. The proof of that is that he got patents around the world for it, so strong that everyone else had to wait for the patents to expire before they could do any kind of vortex based bagless cleaner.
No one is claiming Apple invented the mouse. But they have invented plenty of other things. Never heard of the Bose thing.
All three are indeed talented at marketing. But that doesn't mean they are not also talented at inventing and engineering. Dyson and Apple are that too. Don't know about Bose.
The balance between functionality and cost of space changed. If anyone is not using asserts for the reason of saving bytes, on anything other than a tiny embedded device, they are severely misguided.
Have you heard of Code Complete? If you're a programmer, you probably should have read it. You should probably have a copy in your bookcase. Go read what it has to say in it's section on Assertions before you post any more ill-informed comments on this thread.
Because on failure assert() calls abort(), which is a good behavior if you're debugging code but is unacceptable for code shipped out to customers.[*]
There are several categories in which it's not only acceptable, it's the best thing you can do. e.g. High security issues, data corruption, or other user harm. Look it up in Code Complete for example.
there are other tools to approach it in release mode: if, switch, exceptions
No. Those can only deal with foreseen errors. They can't deal with unforeseen errors.
[*] Image for a moment that you had patched up apache to assert() whether an URL/URI is valid or not, same as here but web-facing Your webserver's uptime would be measured in seconds.
Checking for a valid URL is a foreseen error, and so shouldn't be an assert. It can be handled reasonably because we've predicted it. That doesn't mean that valid uses for asserts in release code don't exist.
Not if the worst case scenario of the assertion not being true is data corruption.
Then instead of an assert you should have a return error (or throw exception) statement.
No. Those can only ever be for foreseen error states. If they are not foreseen, then they are no documentable, and therefore the calling code can take no sensible action to react to the error or exception.
An assert is a documentation of something that's always true and will never fail. If it fails, that's a bug, and there's no graceful handling of bugs - if you could foresee them, you would have already fixed them.
The question is whether to only have them in debug builds or whether to have them in release builds too. Contrary to your ASSERTION, asserts aren't necessarily compiled out of release builds. The answer is they go in release builds too if the worst case scenario is data corruption from continuing in an unpredictable state.
None of this is in Programming 101. This is stuff you learn when you've been programming a long time.
That's only one of it's purposes.
It's general purpose is to give physical form to assumptions in the program itself. It both assures that the assumption *is* always correct past that point, and it documents it.
A novice programmer might say, don't make assumptions. But real programmers make reasonable assumptions all the time. For example if you've just written code to calculate an count, and that calculation can't make a number that's zero or less, then that's a valid assert.
Totally and completely fucking wrong. A well written program should not crash for any reason.
All reasonable length programs have bugs. It's a fact of life.
It should alert the user and allow new input or fail gracefully, not suddenly crash. Asserts should always be compiled out in release code, and cause premature return from the function with an error code or reasonable default, it should NEVER crash on release.
There is no absolute rule on this. It depends on your local coding standards and it depends on the language and platform you're using. There's lots of well written software with release build asserts in it.
Crashing on an assert isn't the worst thing a program can do. Crashing on something that's not an assert is worse, because you don't get the helpful log error that pinpoints the cause. And causing data corruption is far worse still.
I have also had the impression that assert() is a hack that shouldn't be used much (?).
It should be used rather a lot. Every time you believe you know something will always be true, but might break if it wasn't, you should put an assert there.
There's no point putting an IF there, because you can't forsee the case where it will be taken. Likewise an exception - exceptions are for foreseen error states. And ignoring it will result in a harder to find bug if that belief is ever wrong.
It's pretty rare when the bug exists in the assert, rather than the main code. Rarer still when it's an assert that is active in release builds. This is one of those cases. But it doesn't mean that asserts are a bad thing.
Being a programmer is no great claim here. It's almost expected.
And no, it's certainly not a sign of lazy programming. It's the sign of a bug. Everyone creates bugs, not just lazy programmers. And unit testing doesn't approach covering every eventuality. At best it covers easily predicted bugs and regressions.
The user never types in a null terminated string.
Bad assumption. You might not intend for the user to type in a null terminated string. But that doesn't mean he can't or won't - depending on the platform. Either because the platform doesn't filter out the ctrl-shift-2 combination, because it's being pasted in, or because it's being piped in.
Classic.
It has nothing to do with debris; that's just something you made up to justify an obvious over-reach.... Notably missing is durability of the fan blade, a strong hint that it has nothing to do with debris.
Its not made up, it's taken from a presentation on this particular regulation. Sorry if your Google search didn't find it for you. It'll probably take me 10 minutes to find it. If you guarantee me an apology for wasting my time, when I show you, I'll go find it for you.
Durability of the fan is irrelevant, given that we are talking about fault conditions, not normal use. Things break.
Not universally true. Google'sbusiness model is to give away products (search, Android etc.) for free, then get their money from advertisers. You are the product.
For Apple and Blackberry, they make their money from selling you a phone. You are the customer.
This is reflected in the amount of privacy you get with the respective mobile phone platforms.
Because Mac Pros are a niche that doesn't sell that many units. As such they haven't done a redesign in a long time.
There is a new one coming along this year though. Smart bet is it'll be released at the WWDC in June.
Just because you don't understand the reason for a reg doesn't mean the reg is unreasonable. It was put there by someone who knows the issue better than you.
In this particular case you're making the same mistake that all the other critics are making. You;re assuming that this is about people putting fingers into the fans rather than what happens when larger fans break and fragment, and there's fly debris.
That's how I know you don't even know what's in the reg, let alone whether it's justified.
It's nothing to do with handing wires, or probing fingers. It's to do with what happens in those rare cases where a fan fragments. And it only applies to fans that are dangerous in this instance, as judged by a formula or density and max-speed.
The inside of a Mac Pro is an operator accessible area, not a service area. It's expected for users to open them. And they should be protected from injury due to manufacturing faults when they do so.
If you want to rely on the idea that the machine is off when the case is opened, then that would require safety cut-off switched that made that happen. Calling people morons doesn't cut it - ordinary people just forget - or have a reason for running it whilst open.
When it comes to safety regs, the potential people that are inconvenienced are manufacturers. The potential people who are benefited are the consumers who aren't killed or injured.
Clearly, in this regard, the regulators (the EU) they are the servants of the people, not the wealthy.
It's certainly not always that way round. But it's a stupid criticism to make in this case.