|
As opposed to an undetectable infinite loop?
Time is the differentiation of eternity devised by man to measure the passage of human events.
- Manly P. Hall
Mark
Just another cog in the wheel
|
|
|
|
|
Indeed.
The compiler isn't magic, and there are constructs which are obvious infinite loops to a human which the compiler cannot detect as such.
For example:
switch (x)
{
case 1:
while (x < 42);
case 2:
return 123;
} Whilst we can clearly see that the loop is infinite, since x starts as 1 and is never modified within the loop, the compiler still complains:
Quote: CS0163 Control cannot fall through from one case label ('case 1:') to another
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
In my student days, "correctness proofs" were the rage. Everyone were convinced that soon, a program would be able to prove (or disprove) that a program behaved according to specifications.
The first real proof we learned in that course was not a program, but a logical proof that no program analyzer can, in the general case, detect every possible infinte loop. I did understand the proof then; I don't remember the details today, and even if I found the text, I would probably be unable to explain it to someone unfamiliar with it. But I know the proof exists (just like I know that there exists a proof that you cannot trisect an arbitrary angle); I trust the experts that the proof still holds.
|
|
|
|
|
I agree with a specific "end of case" being required - as Richard quoted, it allows the compiler to spot code faults instead of letting them cause runtime problems.
It may be "unnecessary", but it does trap some errors which could be difficult to diagnose at run time.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
It does allow multiple "entry points", so
case 1:
case 2:
Some code
break;
So it can't just assume a break. Sure they can come up with rules for how it would be interpreted, but kind of glad they didn't.
|
|
|
|
|
Personally, I'd have preferred multiple entries to be a different syntax:
case 1,
2,
3:
... code
break;
case 4:
... code
break; Or even:
case 1,
2,
3:
{
... code
break;
}
case 4:
{
... code
break;
} I think it would have been clearer as well as less easy to mess up by adding a new case between them. Perhaps with brackets round the case list as well?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: Or even:
case 1,
2,
3:
case 4:
The Pascal style (except for the 'break' statements). I don't like the C# 'No fallthrough except when the case alternative is empty', so I sort of agree with you, although it is not a big matter.
I do upset some people by always using braces, like in your second alternative: Indentation and braces go hand-in-hand. Call it 'two-factor level nesting'. I want to indent the case alternative, so it should be made a block. Blocks are indented. Statements are not, neither single nor multiple statements. In- and un-denting without braces makes a mess of nesting levels.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
You only need braces in the case when you're creating a new variable in the case. Otherwise, they're unnecessary.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I didn't know this (C# is not my main language) and now it makes sense. From the compiler errors I supposed it didn't allow multiple entry points as well, just like VB6 used to do.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
The shortest horror story: On Error Resume Next
|
|
|
|
|
I blame Ken Thompson.
switch should never have had fall-through, break should never have affected switch . That should have been their first clue.
|
|
|
|
|
I blame Ken Thompson for the vast majority of bugs in today's software. The entire concept of null terminated strings and buffers is simply asking for trouble. DEC and IBM both had descriptor-based buffers, which gives the OS calls that manipulate buffers a way to block buffer overflows.
|
|
|
|
|
Nice, but... which OS?
There are no OS where we are going.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
The shortest horror story: On Error Resume Next
|
|
|
|
|
C was just an easier, portable assembly language.
I blame the overflow buffer errors on the chip designers that encouraged storing local variables on the call stack! Call stack pointer should be read only except for jsr and ret instructions.
|
|
|
|
|
Default fallthrough is one of the major reasons why C is called a machine independent assembler.
Or of you like: A yafi-ygi language.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
trønderen wrote: C is called a machine independent assembler.
That's why I love it
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
The shortest horror story: On Error Resume Next
|
|
|
|
|
I will propose a related extension to C#: Default fall through to the next method.
If the flow runs out of a method body's closing brace, with no explicit return statement, execution continues to the following method.
This would be very useful e.g. for methods that take arguments of two different kinds, say integer and string: The first method would accept, say, a numeric string and convert it to a binary integer, then flowing on to the following method doing the processing on binary integers, regardless of which entry point was used. Fortran has (or had?) its ENTRY statement providing this kind of functionality.
While multiple entry points can be simulated by the first method explicitly calling the other, after format conversion, this adds a completely unnecessary statement, as well as a handful unnecessary instruction for the call management, and increased stack demands.
I cannot think of any single use case were switch case fall through is well justified, and where the arguments for it can not reasonably be extended to justify method fall through. If one makes sense, so does the other.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
int method ( int integer )
{
return ( 42 );
}
int method ( string trigger )
{
return ( method ( Int32.Parse ( trigger ) ) );
}
Gus Gustafson
|
|
|
|
|
yes, but the "new" switch expression 🤤
|
|
|
|
|
Allowing fall through code was/is a huge source of bugs, and does not fall in line with best practices.
During any refactoring, it's not uncommon to move/reorder code. Without close scrutiny, a break in logic flow would be so easily introduced by missing the fall through code.
Worse, refactoring/reordering code might be necessary, but now fallthrough code has introduced an artificial constraint.
For case statements with few case points, this requirement is a minor inconvenience at best.
If, however, you have numerous case points, this might be indicative of a code smell. Such code is both difficult to understand and to follow.
Perhaps a different approach might be more appropriate... fi ite state machines, keyword/lambda method dictionaries, etc.
Something to consider when designing well crafted code that adheres to best practices.
|
|
|
|
|
Allowing fall through code was/is a huge source of bugs, and does not fall in line with best practices.
During any refactoring, it's not uncommon to move/reorder code. Without close scrutiny, a break in logic flow would be so easily introduced by missing the fall through code.
Worse, refactoring/reordering code might be necessary, but now fallthrough code has introduced an artificial constraint.
For case statements with few case points, this requirement is a minor inconvenience at best.
If, however, you have numerous case points, this might be indicative of a code smell. Such code is both difficult to understand and to follow.
Perhaps a different approach might be more appropriate... finite state machines, keyword/lambda method dictionaries, etc.
Something to consider when designing well crafted code that adheres to best practices.
|
|
|
|
|
That isn't true.
switch (value)
{
case 0:
case 1:
case 2:
break;
}
|
|
|
|
|
well.. you could also use return , throw or goto case 3 instead of break .
I guess they didn't want to define a default behaviour witch needed to be remembered and thought of by of everyone, when writing a switch case.
|
|
|
|
|
Got an email from Dell that some of my data had been compromised. They don't think any financial data was stolen. Another one, sigh.
It seems to me that the people on the dark side have it much easier. I have to screw around with passwords, text messages, and some ugly Microsoft security application on my phone to get to my data.
They just click. Doesn't seem right.
Oh well, every hundred years, all new people.
>64
It’s weird being the same age as old people. Live every day like it is your last; one day, it will be.
|
|
|
|
|
The fact that the only thing you get from the companies is an email with vague excuses like "We f***ed up, and your data are compromised. We are sorry, but it will not happen gain. Well maybe, but honestly, we do not really care, as it has no influence on our business. Too bad you susbcribed !" when they are hacked is the worst part of all. They do poorly, your data is exposed, but the get away with a simple email. This is crazy.
|
|
|
|
|
I'm rather selective about what information it is I'm being asked for, and if I can get away with BS answers, that's what they'll get.
I'd rather feed the beast that is Amazon and let them have my details, rather than spread around my credit card data to a dozen mom and pop shops who invest basically nothing to secure the data they collect.
|
|
|
|