Cook: security things in Linux v5.0
While the C language has a statement to indicate the end of a switch case ('break'), it doesn’t have a statement to indicate that execution should fall through to the next case statement (just the lack of a 'break' is used to indicate it should fall through — but this is not always the case), and such 'implicit fall-through' may lead to bugs. Gustavo Silva has been the driving force behind fixing these since at least v4.14, with well over 300 patches on the topic alone (and over 20 missing break statements found and fixed as a result of the work). The goal is to be able to add -Wimplicit-fallthrough to the build so that the kernel will stay entirely free of this class of bug going forward. From roughly 2300 warnings, the kernel is now down to about 200. It’s also worth noting that with Stephen Rothwell’s help, this bug has been kept out of linux-next by him sending warning emails to any tree maintainers where a new instance is introduced (for example, here’s a bug introduced on Feb 20th and fixed on Feb 21st)."
Posted Mar 13, 2019 18:38 UTC (Wed)
by zblaxell (subscriber, #26385)
[Link]
"-Werror=implicit-fallthrough" would be more effective, but you'd have to get all the way to zero warnings first.
Posted Mar 13, 2019 19:12 UTC (Wed)
by rweikusat2 (subscriber, #117920)
[Link] (105 responses)
What about "fixing" people writing code in C (the language is not that complicated, mind you) instead of inventing one bazillion
Posted Mar 13, 2019 19:15 UTC (Wed)
by corbet (editor, #1)
[Link] (101 responses)
Posted Mar 13, 2019 19:35 UTC (Wed)
by rweikusat2 (subscriber, #117920)
[Link] (93 responses)
The C switch statements has certain properties. One could argue whether all of these properties are really desirable, but that's not going to change it. And adding /** I really disagree **/ comments to source code doesn't improve that (the code).
I have to open three different locks with three different keys when trying to get into my flat. Two of them even look identical and can only be distinguished by knowing their relative positions on the keyring. This is vastly more complicated than remembering that a break needs to be added to the end of 'a switch case 'if execution of code in the corresponding block is supposed to be terminated. Yet, human beings without any higher qualifications are expected to be able to do the former while it is claimed that "nobody" can do the latter. Strange, isn't it?
Whenever people have to make a decision, they'll sometimes get this decision wrong. But they will usually get it right most of the time, as evidenced by the miniscule number of missing breaks (compared to the size of the codebase) found during the course of this (a Linux source I happen to have lying around here contains 45,021 switch statements. 20 missing breaks in n * 45,021 cases, n > 2, is decidedly miniscule).
Posted Mar 13, 2019 19:40 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Mar 13, 2019 19:43 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (51 responses)
All the empirical evidence including plenty of research and billions of dollars spent on fixing bugs in such code clearly indicates otherwise.
> And adding /** I really disagree **/ comments to source code doesn't improve that (the code).
That's not really what is happening here though. The specific comment here is being parsed by the compiler and therefore really is part of the code.
Posted Mar 13, 2019 20:38 UTC (Wed)
by rweikusat2 (subscriber, #117920)
[Link] (50 responses)
Posted Mar 13, 2019 20:45 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (49 responses)
Lots of tooling existed before but being part of the compiler makes them more readily available and even better if it is the default.
Posted Mar 13, 2019 21:38 UTC (Wed)
by rweikusat2 (subscriber, #117920)
[Link] (48 responses)
/* fallthru */
to express that they were actually planning to use a certain language feature in a machine-readable way is seriously old. The effect of this is that features someone considers particularly disagreeable become somewhat more complicated to use and that the code becomes cluttered (to a degree) with completely useless comments. Presence or absence of such comments doesn't indicate anything about correctness or incorrectness of the code.
Posted Mar 14, 2019 6:33 UTC (Thu)
by epa (subscriber, #39769)
[Link] (42 responses)
Posted Mar 14, 2019 16:19 UTC (Thu)
by rweikusat2 (subscriber, #117920)
[Link] (41 responses)
Posted Mar 14, 2019 18:31 UTC (Thu)
by HelloWorld (guest, #56129)
[Link] (38 responses)
Besides, this has been standardized in C++17. The only reason it's not in C is that the C committee is run by a bunch of stick-in-the-muds.
Posted Mar 14, 2019 21:19 UTC (Thu)
by rweikusat2 (subscriber, #117920)
[Link] (35 responses)
It is claimed that the semantics of switch, specifically, that it provides a way to jump to a certain location in a block but no automatic exit from there before the code tagged with the next case-label starts, are problematic. Assuming this problem exists (cf next paragraph), adding a metasyntactical sort-of language extension requiring an explicit something in both cases doesn't solve it. It just punishes people who need the fallthrough semantics. What would solve it would be to add another syntactic construct providing an actual multiway conditional, where the code blocks associated with the cases are independent of each other and at most one will be executed.
As to the "problematic", are we perhaps totemically repeating some "But that's not how I think it should be done!"-complaints someone initially made at least 40 years ago which since keep being repeated out of habit? According to the numbers in the text, about 99% of the warnings were false positives. Comparing the number of case-labels in a current -stable tree with the number of missing breaks indicates that this aspect of the code was correct in about 99.99% of all cases. This doesn't look like a "common" problem to me.
Posted Mar 14, 2019 23:03 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (30 responses)
That's why other more modern languages (C#, Go, ...) have ditched that stupid semantics.
And yes, it's stupid. So stupid that the very first linter for C had the "forgotten break" inspection.
Posted Mar 15, 2019 15:56 UTC (Fri)
by rweikusat2 (subscriber, #117920)
[Link] (29 responses)
I agree that the fallthrough is mostly useless and that all the time people and computers wasted by typing or processing
break;
statements could have been put to better uses. But overloading the syntax supposed to be used for inline documentation so that yet more useless code has to be added is not the answer, it's the problem taken to the next power.
Posted Mar 15, 2019 20:46 UTC (Fri)
by myxie (subscriber, #127909)
[Link] (28 responses)
I'm almost scared to look up the semantics of continue inside a switch statement.
Posted Mar 15, 2019 21:15 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link]
Posted Mar 15, 2019 21:36 UTC (Fri)
by madscientist (subscriber, #16861)
[Link] (26 responses)
The main problem is K&R chose the wrong "default" behavior. Usually you DON'T want to continue, so that should have been the default (that is, the current case is automatically terminated by the next case or the end of the statement), and there should be a special keyword used only when you DO want to fall through.
The one exception is empty cases ("case a: case b: case c: foo(); break;") A special dispensation could have been made that the keyword is not needed to fall through unless there are other statements in the case: empty cases don't need the keyword.
Of course, you need a different keyword. They could have used "continue", but both "break" and "continue" are already useful from within switch statements (to break out of or continue an enclosing loop) so using either one of them as meaningful inside a switch was (IMO) not a good decision. I've definitely run into situations where I wanted to break out of a loop from within a switch statement and having "break" overloaded is annoying.
A "fallthrough" or "nobreak" keyword would have been fine. Or if you REALLY didn't want to add a keyword you could have played tricks with "goto", maybe, allowing "goto case X;" where "case X:" existed somewhere in the current switch statement, plus "goto default;"
But that's not the language we have, so FALLTHROUGH-type comments that are recognized by the compiler are great things and everyone should use them. Even if they're weren't recognized by the compiler, they're recognized by the next programmer to come along and read the code, and make clear that you didn't forget something, so they should still always be used.
Posted Mar 15, 2019 21:44 UTC (Fri)
by rweikusat2 (subscriber, #117920)
[Link] (22 responses)
They make clear that someone was using lint (or similar). Not particularly interesting and technically useless as the default case is - well - the default case. Whether or not this is correct is a different conversation, but that's something which can only be determined by looking at the code. There's no more reason to assume that two cases with fallthrough are correct or incorrect than two cases seprated by a break;. I've actually written code where I forgot to omit the break in the past :-).
Posted Mar 15, 2019 22:42 UTC (Fri)
by madscientist (subscriber, #16861)
[Link] (20 responses)
I'm not going to get drawn too far into this conversation because it's ridiculous, but I'll say that the above is at best missing the point.
A fallthrough comment is not trying to tell you whether or not the code will fall through. Obviously it will, there's no break! The comment is telling you that someone thought about it and INTENDED the fallthrough to happen.
If lint or the compiler warns someone about a missing break and they want a break, they'll obviously just add a break. If they get a warning and they intended to fallthrough, they will add a fallthrough comment. If they didn't add either one then you don't know whether they thought about it and intended the fallthrough, or they just forgot.
Of course, even with the comment the fallthrough behavior could be a bug. Code has bugs. But the comment is not telling you the code is bug-free, it's telling you that it's intentional, rather than an omission. That's still a big benefit.
Posted Mar 17, 2019 20:29 UTC (Sun)
by rweikusat2 (subscriber, #117920)
[Link] (19 responses)
It's usually safe to assume that code came to be in a certain form because someone was convinced it would be the right way to solve a particular problem. But that's not particularly interesting. Interestsing is "is it the right way".
Posted Mar 18, 2019 13:49 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link] (18 responses)
Posted Mar 18, 2019 16:14 UTC (Mon)
by jezuch (subscriber, #52988)
[Link]
Posted Mar 18, 2019 19:40 UTC (Mon)
by rweikusat2 (subscriber, #117920)
[Link] (16 responses)
I was trying to express two things:
1) Noting that a break is absent isn't sufficient grounds to assume that this must have been an oversight unless there's an a priori conviction that this is a very likely cause for an absent break. Considering the "99% false positives", such a conviction doesn't seem sensible to me.
2) Computers execute code as it was written, not as it was intended to be written. An absent break which was an oversight isn't necessarily an error. And neither is a conscious omission or a present break necessarily correct.
Posted Mar 18, 2019 19:53 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link] (15 responses)
Posted Mar 18, 2019 21:46 UTC (Mon)
by rweikusat2 (subscriber, #117920)
[Link] (14 responses)
Posted Mar 18, 2019 22:11 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (9 responses)
Posted Mar 18, 2019 22:29 UTC (Mon)
by rweikusat2 (subscriber, #117920)
[Link] (8 responses)
As person who spends a seriously lot of time working with other people's code (and has done so for about 15 years), I can assure you that I don't give $random_small_quantity_of_money for documentation of "programmer intent", especially not in form of otherwise uninformative comments. I need to know what the code does, not what someone believed it should be doing.
Posted Mar 18, 2019 22:33 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Correctness checking is TRIVIAL, it's not even worthy of mentioning. Checking of intent is anything but. And that's exactly why modern computer languages try to make it easier for developers to express their intent through code.
Posted Mar 18, 2019 22:39 UTC (Mon)
by sfeam (subscriber, #2841)
[Link]
Posted Mar 19, 2019 12:24 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (5 responses)
The goal of computer programming is to write code that does what it is supposed to be doing. You can use the code itself to figure out what it does, but you can't use the code itself to figure out whether it does what it is supposed to be doing.
It's very easy to write code that does something. Writing code that does what it it supposed to do is a lot harder, and requires outside context so you can determine when you're done. This is why in Real Life™ we have comments, specifications, unit tests, and so on – all to be able to figure out whether code does what it is supposed to do.
Posted Mar 19, 2019 14:14 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link] (4 responses)
Posted Mar 19, 2019 14:31 UTC (Tue)
by NAR (subscriber, #1313)
[Link] (3 responses)
How can you check correctness when you don't know what that code is supposed to do?
Posted Mar 19, 2019 14:43 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Posted Mar 19, 2019 14:55 UTC (Tue)
by NAR (subscriber, #1313)
[Link] (1 responses)
You're making the assumption that this particular access was not intended. So intent matters.
Posted Mar 19, 2019 14:59 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
Posted Mar 19, 2019 10:02 UTC (Tue)
by NAR (subscriber, #1313)
[Link] (3 responses)
Let's say I have this code snippet:
Posted Mar 19, 2019 21:44 UTC (Tue)
by neilbrown (subscriber, #359)
[Link] (2 responses)
Yes it is.
Posted Mar 19, 2019 22:03 UTC (Tue)
by pizza (subscriber, #46)
[Link] (1 responses)
Posted Mar 19, 2019 23:24 UTC (Tue)
by neilbrown (subscriber, #359)
[Link]
Sorry to correct you, but I think you mean "It is correct that 'The Therac-25 killed three people' ".
And this is the point - when people start using broad terms like "intent" and "correct" without ensuring that all corespondents are using them in the same sense, you can hardly expect a useful conversation to result.
(wouldn't it be great if people would think about what they write, instead of just writing about what they think).
Posted Mar 19, 2019 10:37 UTC (Tue)
by HelloWorld (guest, #56129)
[Link]
> I've actually written code where I forgot to omit the break in the past :-).
Posted Mar 15, 2019 23:15 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link]
Posted Mar 16, 2019 23:53 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (1 responses)
switch nofallthrough {
As for break being overloaded, can't remember the language but it was something like
labela: for i = 1 to 10
so break or continue could take labels to indicate which construct they were meant to break out of.
Cheers,
Posted Mar 17, 2019 0:28 UTC (Sun)
by ABCD (subscriber, #53650)
[Link]
Among possibly other languages, Java allows this:
Posted Mar 15, 2019 7:11 UTC (Fri)
by HelloWorld (guest, #56129)
[Link]
Posted Mar 15, 2019 13:33 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (2 responses)
That would help. But programs using this construct would no longer be C programs. If sticking to a popular and well-understood language standard is of value to you (which makes sense in a large community like the Linux kernel crowd), then this is something not to be thrown away lightly.
OTOH, code that uses the “metasyntactical sort-of language extension” is valid C whether the compiler pays attention to it or not. But if you have a compiler that does pay attention, it's probably a good idea to exploit that, much like we exploit our compiler's paying attention to all sorts of other little things that might otherwise slip us by (think “if (foo = bar) …”).
Like a surgical scalpel, the C programming language is conceptually pretty simple but using it still requires considerable care and attention to detail. I haven't done lots of C programming recently but when I do I'm humble enough to appreciate all the assistance I can get.
Posted Mar 15, 2019 15:51 UTC (Fri)
by rweikusat2 (subscriber, #117920)
[Link] (1 responses)
BTW, I've come to dislike if (a = b) warnings as well: Mistyping == as = is another, extremely rare error and some things will always have to be found and fixed via code rewiev and/ or testing. Algorithmic errors are far more common than any kind of syntax misuse.
Posted Mar 15, 2019 17:52 UTC (Fri)
by anselm (subscriber, #2796)
[Link]
You want code review and testing, but you also want reasonable compiler warnings. If a developer is made aware of a “==” vs. “=” typo by a compiler warning while they're writing the code in the first place, the issue doesn't even come up in code review or testing (where it would be more expensive, in terms of developer time, to detect and fix). This is what in security circles we call “defense in depth”.
Yes, but the syntax problems still exist and are often easier to detect and fix. This is like saying garbage in the street is not important because there are millions of children starving in Africa.
Posted Mar 15, 2019 15:28 UTC (Fri)
by jrigg (guest, #30848)
[Link] (1 responses)
Posted Mar 16, 2019 9:22 UTC (Sat)
by HelloWorld (guest, #56129)
[Link]
Posted Mar 15, 2019 8:53 UTC (Fri)
by epa (subscriber, #39769)
[Link] (1 responses)
A language extension is a great idea. GCC effectively provides a GCC-specific extension to the C language here -- or perhaps you could call it a restriction, since the code allowed with -Wimplicit-fallthrough is a subset of that without the warning. Either way, it's useful in practice to many programmers, and Linux has started making use of it. Pushing it upstream to the ISO C standard would be better still of course.
Posted Mar 15, 2019 10:28 UTC (Fri)
by HelloWorld (guest, #56129)
[Link]
Posted Mar 16, 2019 5:09 UTC (Sat)
by scientes (guest, #83068)
[Link] (4 responses)
Posted Mar 16, 2019 9:25 UTC (Sat)
by HelloWorld (guest, #56129)
[Link] (3 responses)
Posted Mar 16, 2019 21:32 UTC (Sat)
by zlynx (guest, #2285)
[Link] (2 responses)
Preprocessed files do not include comments.
To fix this, you can of course use whatever compiler flag disables this switch case check.
Posted Mar 17, 2019 10:49 UTC (Sun)
by HelloWorld (guest, #56129)
[Link]
Posted Mar 17, 2019 12:30 UTC (Sun)
by madscientist (subscriber, #16861)
[Link]
However, using attributes is probably a better way to go in general.
Posted Mar 13, 2019 20:27 UTC (Wed)
by roc (subscriber, #30627)
[Link] (31 responses)
Absent the kind of work described here that you are objecting to, omitting a "break" is not immediately detected and can have lasting consequences up to and including users you don't even know having their systems compromised by hostile forces.
It would be a better analogy if every time you touched a lock with the wrong key you got an electric shock. It would be interesting to see how long you tolerated that situation because "human beings without any qualifications should be able to do this".
Posted Mar 13, 2019 20:35 UTC (Wed)
by rweikusat2 (subscriber, #117920)
[Link] (30 responses)
That I happened to use an example to illustrate something specific (complicatedness of a procedure) doesn't mean any side properties of said example are relevant to the discussion because they exist (or are believed to exist).
Posted Mar 13, 2019 21:12 UTC (Wed)
by roc (subscriber, #30627)
[Link] (29 responses)
I don't expect people to put the right key in the right lock first try every single time, just like I don't expect C developers to always remember to put "break" after switch cases. But because the consequences of the former are "it didn't work, try again" (i.e. negligible), it *is* reasonable to expect unskilled people to successfully enter their flat. The goal of the changes reported here, which you apparently oppose, is to change the consequences of omitting a "break" to something similar (whereas currently the consequences can be much more severe and fall on other parties).
Posted Mar 13, 2019 21:50 UTC (Wed)
by rweikusat2 (subscriber, #117920)
[Link] (28 responses)
Just out of curiosity: Have you ever seen a bread slicing machine? Chances are that someone who doesn't get "using that" right every time will end up cutting off a part of his or her fingers. That's a seriously bloody and quite painful experience. Yet, people without a degree in anything are expected to be able to do that.
NB: This is still completely besides the point I was trying to make, it just illustrates that "misues of household devices is harmless !!! but misuse of switch Catastrophical !!1" is an nonsensical assertion despite misuse happend to be harmless for an example I used because it served as illustration for something completely different.
Random story I feel like telling here: A couple of years ago, I read about a guy who was resolved to commit suicide and thus, turned the gas on in his kitchen. After waiting for terminal results for a while, he suddenly changed his mind, turned the gas off again and opened the kitchen window. To celebrate his decision to face this life somewhat more, he then lighted a cigarette. The roof of the house was blown of but he survived with serious burns and was later sentenced for arson.
Posted Mar 13, 2019 21:59 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (18 responses)
In reality people make mistakes. A lot of time.
A good example here is surgery. A surgeon is a highly trained professional, you need almost a decade of intense training for it. In short, a surgeon is the first candidate for somebody who shouldn't make stupid mistakes.
Yet surgeons forgetting instruments inside patients was a common occurrence before a simple check was added - nurses count surgical instruments before and after the surgery.
Aviation? The same issue. Solved by checklists that HAVE to be followed.
Posted Mar 14, 2019 6:35 UTC (Thu)
by adobriyan (subscriber, #30858)
[Link]
Current situation is further complicated by very low barriers to entry.
Posted Mar 14, 2019 12:16 UTC (Thu)
by jem (subscriber, #24231)
[Link]
Posted Mar 14, 2019 16:31 UTC (Thu)
by rweikusat2 (subscriber, #117920)
[Link] (1 responses)
Switching the topic of a discussion away from something technical and towards posting speculative, public insults about people who happen to disagree with some opinion is not a strong point in favour of this opinion. Rather the opposite.
Posted Mar 14, 2019 17:53 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
A cavalier attitude of ignoring the simplest safety features has led the industry down the never-ending rabbit hole of security bugs.
Posted Mar 18, 2019 0:58 UTC (Mon)
by rickmoen (subscriber, #6943)
[Link]
Aviation? The same issue. Solved by checklists that HAVE to be followed. Sadly, there have been some painful (and fatal) lessons in effective use of checklists in the airline industry, as also in other industries where they're critical (marine transportation. weapons systems, spaceflight, medical care, etc.) Making a long story short, checklist design and implementation has had subtle aspects that are difficult to get right, and just saying they HAVE to be followed isn't nearly enough. What happens when airlines get it wrong is what happened to my father, Pan Am Captain Arthur Moen, and his crew. (Upon finally reading the NTSB report, I was obliged to change my saying 'A checklist will have your life' to 'A well-debugged checklist will save your life'.) Rick Moen
Posted Mar 18, 2019 10:18 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (12 responses)
The thing that really changed both aviation and surgery is not checklists themselves, but three shifts in attitude that result in changes (including checklists) that improve on today's situation.
Change 1 is the idea that unforced human error is not an explanation - it's just a way of shifting blame onto the operator. All incidents have to be investigated, and at each point where a reasonable change to procedure or device implementation could have prevented an incident, that change should be identified. Once you have a list of changes that could have prevented this incident, then you do a risk/benefit assessment of each change and decide which ones are worth having, and which ones just add complexity for complexity's sake.
Change 2 is that there's no such thing as a lucky near miss - instead, there are near misses that . Whenever someone has a "lucky near miss", record what happened, and classify it with other lucky near misses. Someone looks for patterns of lucky near misses, and anything that recurs is treated as an incident and investigated with a view to stopping it happening again.
Finally, change 3 is the idea that seniority should not imply deference. The world's greatest experts all make mistakes, and when a junior calls you out on a possible error, you either fix it and graciously acknowledge their input (if they've called you on a real error like operating on the wrong limb), or you treat it as a teachable moment if they've misunderstood something (e.g. if they're asking you why you put the nose down and cut the throttle when trying to descend).
None of this is a panacea - mistakes still get made - but it means that you don't repeatedly make the same class of error, nor do you depend on "experience" and "expertise" to remove classes of mistake, because the changes you make (be it checklists, talking to the patient before operating, gauges rotated so that "perfect" is straight up, sign in/out sheets for everything that's used in an operation, making it normal for juniors to critique seniors) all change the working environment such that fewer mistakes are made.
In contrast, in software, we had the Morris Worm of 1988 (over 30 years ago), which exploited buffer overflows in C code. 30 years later, we're still seeing new buffer overflow attacks on maintained software written in C; why haven't we changed the way we work so that buffer overflows don't happen?
Posted Mar 18, 2019 11:18 UTC (Mon)
by pizza (subscriber, #46)
[Link] (7 responses)
Because, unlike both Surgery and Aviation, "programming" (C or otherwise) as a profession has little to no formal quality, training or certification requirements, and zero government oversight. Which is just they way the industry likes it.
You want this to change? Make software vendors directly liable (civilly and/or criminally) for software defects -- no more hiding behind "the software is provided with no warranty; not even implied merchantability or fitness for a particular purpose" disclaimers.
Posted Mar 18, 2019 11:43 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (6 responses)
That's not sufficient - maritime transport is regulated in the same way as aviation, and yet is as generally disasterous as programming. In particular, maritime accidents can be blamed on human error and the captain or their crew prosecuted in a way that does not happen in aviation - see the Costa Concordia disaster for example, where no lessons are being learnt by the industry because they can push the blame onto the captain.
Posted Mar 18, 2019 12:46 UTC (Mon)
by pizza (subscriber, #46)
[Link] (5 responses)
That said, the cruise industry as a whole also made changes (notably requiring safety drills prior to leaving port instead of "within 24 hours" as the governing treaties require) and much stricter rules about non-essential personnel on the bridge -- eg if you're going to sneak your mistress on board without a ticket, at least keep her off the bridge during offshore manoeuvres.
I might postulate that the "maritime industry" is learning the lesson that poor safety practices will severely hurt them in the market -- both in lower passenger booking and drastically higher insurance premiums. (Indeed, insurance company requirements probably do more to effect industry-wide changes than governments ever do..)
Posted Mar 18, 2019 13:20 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (4 responses)
The Costa Concordia is a good example, because it had a near-miss doing a similar manoevure at company request under the same captain a few months earlier, but no formal investigation happened - it was just one of those things - and even now, the effort is to claim that the captain was at fault.
In an aviation equivalent, the setup would allow any bridge officer to override the captain on a risky manoevure like this; it simply wouldn't be just the captain's fault as the Concordia was suggested to be.
Plus, there are plenty of design issues with the cruise ships in general, which are being completely ignored in favour of minor tweaks to the way they operate - despite knowing that the requirement for active stability assist to stay upright is part of what caused the Concordia to crash.
Posted Mar 18, 2019 15:56 UTC (Mon)
by pizza (subscriber, #46)
[Link] (3 responses)
(FYI, under maritime law, "overriding the captain" is called mutiny, something that tends to go quite badly for all involved..)
Meanwhile, the book wasn't thrown at the captain (and his senior staff) for merely running aground. Instead, it was for grossly mismanaging what happened next. To top it all off, the captain *abandoned his post* well before evacuation was complete.
Posted Mar 18, 2019 16:50 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (2 responses)
Exactly my point - there are two things that matter and are different in aviation as opposed to maritime regulation:
It's that blame culture that prevents maritime rules from moving on - we have a scapegoat for the incident, we don't need to consider anything other than Captain Schettino's bad behaviour. In the aviation world, there would be more significant changes expected; why does Captain Schettino claim he was asked to do a sail-past salute? Why can't a more junior officer order preparations to abandon ship? Why couldn't Captain De Falco hand command of the ship over to Mr Bosio when Captain Schettino refused to return onboard? Why is it possible for the alarm system to be off on captain's orders alone?
And I'm not a professional investigator - those are just four things raised by the public record on the disaster that should be understood and should lead to changes to the way ships are run, if it's managed the way aviation is. Human error happens, and the rates at which it happens are well understood, so why do we accept that the disaster was Captain Schettino's fault, and leave it at that, when we should be trying to ensure that the next Captain Schettino cannot make the same set of mistakes?
Posted Mar 18, 2019 17:20 UTC (Mon)
by pizza (subscriber, #46)
[Link] (1 responses)
BTW, here is the 181-page official investigation report:
http://3kbo302xo3lg2i1rj8450xje-wpengine.netdna-ssl.com/w...
Posted Mar 18, 2019 19:09 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
I don't disagree that a lot of the issues are down to maritime law - but that's precisely the sort of thing that needs to be fixed if maritime is to catch up on aviation w.r.t. safety errors. And (to circle back round) both aviation law and maritime law are government regulations on the way their respective industries are run, complete with liability control; however, one has a strong record of ratcheting up safety over time, and the other continues to blame individuals rather than address the many ways in which changes to the law would result in better safety for all.
Hence my belief that regulation, in itself, is not sufficient to improve software - it needs to be good regulation like aviation, where the emphasis is on changing the regulation to prevent repeats, not like maritime law where flag administrators are slow to change regulations in response to known deficiencies.
Posted Mar 19, 2019 14:43 UTC (Tue)
by NAR (subscriber, #1313)
[Link] (3 responses)
According to this study, checks for buffer overflows in C can lead to 0-7% percent performance loss. Checking for integer overflow could lead to 50% slowdown. I guess those who still want to work in C don't want to accept this performance degradation.
Posted Mar 19, 2019 19:13 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Unfortunately, C made that useless and so it fell by the wayside.
Posted Mar 19, 2019 19:36 UTC (Tue)
by mpr22 (subscriber, #60784)
[Link] (1 responses)
Posted Mar 20, 2019 1:18 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Ada has had integer overflow checking since forever (as you would expect).
Posted Mar 13, 2019 22:17 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (7 responses)
And yet both of those examples (bread slicers and kitchen gas) have been changed over the years to reduce the chances of not using them correctly, and to make sure that it takes continued incorrect operation in the face of a machine trying to stop you before you hurt yourself. Unlike C, you have to actively work to hurt yourself with modern designed appliances.
Modern bread slicers are designed such that you need the guard down over the bread to allow the slicing action to run; you can't have your fingers near the bread, but the guard holds the loaf in place when it's held in place. On high speed slicers, the guard is the trigger mechanism - you put the unsliced loaf in, push the guard down, loaf is sliced and machine pushes on the guard to tell you to release it and move onto the next loaf.
This compares to older slicers, where the blades are exposed, and there's no interlocking mechanism in place to stop you cutting your fingers - you put the loaf in, remove your hand, and push the trigger.
Similarly, with kitchen gas, older appliances would run the gas forever once you turned it on; modern appliances cut the gas the moment you let go of the controls unless the burner is hot, and will cut it if the burner cools off too far (implying flame lost). Further, they will stop the gas flow after a fixed time period if the burner remains cold, to reduce the chance of accidentally holding the control down without lighting the gas, and then blowing yourself up. It's thus very, very hard to actually get enough gas out of an appliance to trigger an explosion, even if you're trying to do it.
Posted Mar 14, 2019 2:00 UTC (Thu)
by martinfick (subscriber, #4455)
[Link] (4 responses)
Posted Mar 14, 2019 3:14 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Mar 14, 2019 9:30 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
Unfortunately, the mechanical mechanisms used for gas safety are based on the idea that you simply permit the flow of gas to run freely when the burner is warm enough; they just stop gas flow when cold, and use pressure on the control knob to open up the flow. The better ones use pressure on the control knob to start a release timer, after which you need to release the control knob and press it again to resume the flow of gas.
As with all safety mechanisms, they're not that hard to get around if you're determined - the point, however, is that a single mistaken decision on its own is not enough to cause a serious problem.
Posted Mar 16, 2019 9:29 UTC (Sat)
by HelloWorld (guest, #56129)
[Link] (1 responses)
Posted Mar 16, 2019 10:30 UTC (Sat)
by roc (subscriber, #30627)
[Link]
Posted Mar 14, 2019 15:31 UTC (Thu)
by nilsmeyer (guest, #122604)
[Link] (1 responses)
Posted Mar 16, 2019 23:58 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
SUGAR can be very bad for you. But one of the biggest problems with carbs is the modern tendency to snack, leading to elevated blood sugar over a long period of time. Our body is designed for sugar levels to sawtooth - high after a meal and then low between meals. Snacking means it never gets a chance to drop, and that does a HELL of a lot of damage.
Cheers,
Posted Mar 13, 2019 22:25 UTC (Wed)
by roc (subscriber, #30627)
[Link]
Personally I'd support people being free to chop off their own body parts if they insist on using unsafe equipment or unsafe programming languages, except that some of the costs inevitably fall on the community at large. For amputations, it's health care costs. For software, it's a combination of things: a software ecosystem polluted with vulnerable software, and a network ecosystem polluted with compromised devices.
The gas story is a good one.
Posted Mar 14, 2019 9:48 UTC (Thu)
by dvdeug (guest, #10998)
[Link]
There's been other problems like this; Fortran require you to declare variables, so when programmers misspelled variable names, the compiler wouldn't warn the programmer. So those still using Fortran have the option of using "IMPLICIT NONE", not too dissimilar to C programmers having an option to have the compiler complain when they don't use a break or a note comment.
Posted Mar 14, 2019 13:45 UTC (Thu)
by dottedmag (subscriber, #18590)
[Link] (1 responses)
Posted Mar 14, 2019 16:34 UTC (Thu)
by rweikusat2 (subscriber, #117920)
[Link]
In theory, we're past the point were "Charge and beat 'em!" was an acceptable discussion tactic.
Posted Mar 14, 2019 15:27 UTC (Thu)
by HelloWorld (guest, #56129)
[Link]
Posted Mar 14, 2019 21:59 UTC (Thu)
by NAR (subscriber, #1313)
[Link]
Accidentally leaving out a break statement in the Linux kernel might not lead to actual accidents (but who knows, Linux is running on cars nowadays), but it's still better to make it safer for those who "just can't learn", just like it's better to make that road crossing safer.
Posted Mar 15, 2019 1:47 UTC (Fri)
by jschrod (subscriber, #1646)
[Link] (2 responses)
As an old Unix grey beard (well, not quite literally, by now my beard is white), I'll have to say that demanding that all kernel programmers are "proficient in math" and "have to learn C" is not sufficient. Some decades ago, I was able to read binary OS/370 code, and did so everyday, not needing disassemblers. Nowadays, not so much any more; but that it is clearly the reason why I'm too old to be a kernel developer. But, since I still remember this time at the start of the 80s, it's not too far away, these kids today should get off the lawn. Obviously, this kind of my then-proficiency should be the standard for all current kernel developers -- they should stop writing that kind of code in C (a.k.a. abstract assembler of PDP-11 hardware) and should start using better abstract assembler for current hardware system abstractions. Since they are these geniuses, this should be no problem at all; if there is no such system, they can invent it. The Unix guys worked shoulder-to-shoulder with the C guys, and did it too, don't they. Insistence on C is so 70s, bring on new assemblers!
IOW: An argument that one should "fix programmers" is as silly as my paragraph above.
FTR: I've known Dennis Ritchie personally, and I'm proud that he took the time sharing several evenings with me. He was the first person who would have called these arguments "you have to learn C properly" not appropriate, since he knew the deficiency of his own creation quite well.
Posted Mar 15, 2019 13:19 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (1 responses)
Not just that. The Unix guys basically were the C guys.
I wonder what all the fuss is about. The C language has its problems but as far as I'm concerned break is not one of the bigger ones. It's more of an idiosyncrasy. To my mind, requiring explicit break statements lets you do useful¹ things that would be impossible if there was an implicit break in front of every case (think Duff's Device), and that, together with the fact that this style of switch is fairly straightforward and minimal to implement in a C compiler based on other stuff you already have, may have been enticing to the designers of the language.
Chances are that if you were designing the C programming language from scratch today you would do various things differently, probably including switch statements. But for better or worse, we're stuck with C – at least the C switch statement – as it has been for almost 50 years, so we must remember to put a break in all the appropriate places. If we can get the compiler to remind us to do that if we forgot, or else to tell it explicitly that we didn't want one, that can only be a good thing – ace programmers of rweikusat2's calibre will of course always do the Right Thing™ from the get-go and should therefore not ever be annoyed by superfluous compiler warnings, but people like you and I (and incidentally like jschrod's, my beard is also fairly white by now) may appreciate an occasional heads-up.
¹ Useful, that is, if you think of C as a high-level portable assembly language.
Posted Mar 15, 2019 18:51 UTC (Fri)
by rgmoore (✭ supporter ✭, #75)
[Link]
You could fix that by allowing an explicit
Posted Mar 14, 2019 15:42 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (6 responses)
It's not about fixing the people - they've already been fixed. When observing people carrying out a task, if they keep doing the same thing wrong, ask yourself why.
It's a pretty safe bet they're doing EXACTLY what they've been trained to do. It's just that the task they're doing is unusual, and their training is making them do the wrong thing.
Case in point - who was the idiot that decided that in Windows "tab" should step between fields, and "return" should send the completed form back to the program. It took a MAHOUSIVE training effort to fix that programming blunder, and people STILL get it wrong on a regular basis.
If people can't do it right, IT'S BECAUSE THEY'VE BEEN TRAINED TO DO IT WRONG, and you've got to *find* that training and fix it - which may not be possible.
(Another case in point - these latest 737 MAX crashes - the plane avionics have changed, and it seems pilots haven't been told that 20 or 30 years of training will make them instinctively do the wrong thing in a crisis ... - TRUE STORY!)
Cheers,
Posted Mar 15, 2019 7:45 UTC (Fri)
by jem (subscriber, #24231)
[Link] (4 responses)
That convention is older than Windows, possibly older than the Apple Mac GUI. The real idiot was the one who later decided to implement this functionality differently on marginal platforms like Acorn's RISC OS.
Posted Mar 15, 2019 9:24 UTC (Fri)
by halla (subscriber, #14185)
[Link]
Posted Mar 17, 2019 0:04 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (1 responses)
(I was programming using text terminals on a mini ...)
Cheers,
Posted Mar 25, 2019 15:45 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
It was the convention on old green screen terminals. It was the convention on teletypes before that. Heck, it's the convention that first came about two centuries ago with the early typewriters!
Just changing the convection won't fix two centuries of training to do the opposite - since when did hitting "return" change the paper for you?
Cheers,
Posted Mar 17, 2019 9:11 UTC (Sun)
by farnz (subscriber, #17727)
[Link]
It was formalised in IBM's CUA guidelines in 1987, which was adopted by Motif. I can't find references for where IBM took that behaviour from, but the fact it was adopted as part of CUA suggests it was in use before 1987.
Posted Mar 16, 2019 17:20 UTC (Sat)
by jezuch (subscriber, #52988)
[Link]
I know I do. I still have to basically relearn switch every time I encounter it. And it took me a lot of time and much mental effort to get it the first time. It's just so freakin' odd.
Anyway, fixing people in face of obviously broken tools (instead of fixing the tools) is never the right answer. It's elitist, condescending, and thinking about it, it could also have a component of Stockholm syndrome.
Posted Mar 14, 2019 18:49 UTC (Thu)
by tdz (subscriber, #58733)
[Link]
I don't see anything wrong with this. Of all the changes from the linked article, this is the least controversial. This has no runtime/compile overhead or any form of weird semantics. It doesn't obfuscate the code base. This change has zero negative impact. If anything, I'd ask for using the related gcc attribute instead of a comment.
Posted Mar 15, 2019 11:24 UTC (Fri)
by jani (subscriber, #74547)
[Link] (1 responses)
I find that more than a little condescending.
Even so, it's not about complexity of the language per se. It's about the complexity of using the language in a way to avoid common mistakes. The problem is in the language, not the people.
> inventing one bazillion /*** OMFG !! Not like Pascal !!! ***/ pseudosyntactic tags?
Granted, I would have preferred __attribute__ ((fallthrough)) with some syntactic sugar macro. But this is one. What are the other (bazillion - 1)? Or even your top three pet peeves?
Posted Mar 16, 2019 5:16 UTC (Sat)
by scientes (guest, #83068)
[Link]
https://lkml.org/lkml/2019/3/15/792
Because it is needed by distcc.
Cook: security things in Linux v5.0
Cook: security things in Linux v5.0
/*** OMFG !! Not like Pascal !!! ***/ pseudosyntactic tags?
Perhaps because humans have this nasty tendency to be ... humans ... who will, when using a language that makes it easy to code certain types of mistakes, make those mistakes? Fixing the people has never been a workable solution to this kind of security issue; why would you expect this case to be different?
Fixing programmers
Fixing programmers
Fixing programmers
The number of CVEs caused by a missed "break" tends to confirm that people suck at math.
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
How is a "fallthrough comment" at the end of a case branch not a language extension, assuming that its presence is enforced by the compiler?
Fixing programmers
Fixing programmers
Why? Switch is fine for this. In 99% of cases it's NOT used as computed goto, so implicit fallthrough is actively harmful.
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
> everyone should use them. Even if they're weren't recognized by the compiler, they're recognized by the next programmer to come > along and read the code, and make clear that you didn't forget something, so they should still always be used.
Fixing programmers
> technically useless as the default case is - well - the default case. Whether or not this is
> correct is a different conversation, but that's something which can only be determined by
> looking at the code. There's no more reason to assume that two cases with fallthrough
> are correct or incorrect than two cases seprated by a break;. I've actually written code
> where I forgot to omit the break in the past :-).
Fixing programmers
> comment is telling you that someone thought about it and INTENDED the fallthrough to happen.
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
So you need to know the intent. Duh. You're just deluding yourself at this point.
I believe you have this backwards. What the code does can be determined in the absence of comments. The intent, not so much. That is why comments are valuable for bug-finding. Any place where the documented intent does not match the observed actual behavior is candidate for causing problems.
Fixing programmers
Fixing programmers
Fixing programmers
what the intent was actually doesn't matter and correctness is all that counts.
Fixing programmers
Fixing programmers
that allows you access to something else that you normally wouldn't be able to access.
Fixing programmers
Fixing programmers
Intent doesn't matter. Correctness does.
Fixing programmers
a = b + c;
Is it correct?
Fixing programmers
Your statement "I have this code snippet: a = b + c" is self-evidently correct.
Fixing programmers
Fixing programmers
Fixing programmers
There are actually two reasons:
– the case where you want to use break is vastly more common than the case where you want to fall through
– it's easier to forget adding the break keyword than it is to accidentally add the fall-through attribute
The article mentions 20 cases of missing break statements that were uncovered by this work, while it doesn't mention any cases like the one you describe. It's safe to say that missing break statements are a much more frequent occurrence.
Fixing programmers
Fixing programmers
case a:
case b:
}
labelb: for j = 10 to 1 step -1
do something
if x continue labela
next
next
Wol
Fixing programmers
labela:
for (int i = 1; i <= 10; i++) {
labelb:
for (int j = 10; j >= 1; j--) {
do_something(i, j);
if (x) continue labela;
}
}
Fixing programmers
Actually it does.
Fixing programmers
What would solve it would be to add another syntactic construct providing an actual multiway conditional, where the code blocks associated with the cases are independent of each other and at most one will be executed.
Fixing programmers
Fixing programmers
Mistyping == as = is another, extremely rare error and some things will always have to be found and fixed via code rewiev and/ or testing.
Algorithmic errors are far more common than any kind of syntax misuse.
Fixing programmers
This could be considered a feature.
Fixing programmers
Yes, by other stick-in-the-muds.
Fixing programmers
Fixing programmers
Or people could just switch to C++ where is this already standardized, along with dozens of other useful features.
https://en.cppreference.com/w/cpp/language/attributes/fal...
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Programming still have yet to grow up which is (slowly) happening.
I have learned that checklists are also being applied in surgery. The first item on the list is to check the patient's name.
Fixing programmers
Fixing programmers
Fixing programmers
Cyberax wrote:
The art of checklists
rick@linuxmafia.com
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
"why haven't we changed the way we work so that buffer overflows don't happen? "
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Pots are made of metal and hence won't burn, and if the food burns, there will be smoke which will trigger the smoke detector, which is mandatory where I live.
Fixing programmers
Fixing programmers
Fixing programmers
Wol
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Fixing programmers
Actually it does. "C with magic comment for fall-through" is a different (albeit similar) language than C, because the compiler actually enforces the comment. And empirically people are less likely to make the fall-through mistake in that language than they are in C.
Take a look at this road crossing. The 2011 October state shows something like the "C switch statement". It's clearly defined in the highway code that the cyclists coming from the north ("behind") have priority, the cars should give way to them. Yet many cyclists were hit in this very road crossing - apparently the drivers "just can't learn" and apply the highway code. So the road crossing was updated. The highway code was not changed (the semantics of the C switch statement did not change), the cars still need to yield to the cyclists. It's the radius of the curve that was changed, so the drivers have to break more, otherwise they can't turn in, and at a slower speed they have more time, more chance to notice the cyclist (the path of the cyclist was also changed, now there's no 250 m straight line before the crossing, only 20 m, so they don't arrive to the crossing at 30 km/h speed). Effectively a "look around carefully" comment was introduced to this "C switch statement".
Fixing programmers
Fixing programmers
Fixing programmers
The Unix guys worked shoulder-to-shoulder with the C guys
Fixing programmers
To my mind, requiring explicit break statements lets you do useful¹ things that would be impossible if there was an implicit
break in front of every casefallthrough when that's what you want. Unfortunately, as you say it's too late to change the syntax now, so the best we can do is use the compiler to catch cases where the break is left out accidentally.
Fixing programmers
Wol
Fixing programmers
Fixing programmers
Fixing programmers
Wol
Fixing programmers
Wol
Fixing programmers
Fixing programmers
Cook: security things in Linux v5.0
Cook: security things in Linux v5.0
submitted