- "Will Carbon Replace C++?" by Manuel Rubio - 1 Update
- Is this safe? - 18 Updates
| Lynn McGuire <lynnmcguire5@gmail.com>: Feb 28 03:35PM -0600 "Will Carbon Replace C++?" by Manuel Rubio https://semaphoreci.com/blog/carbon "The last CppNorth 2022 was announced with Chandler Carruth scheduled to give a keynote, where he showed the results of a new scientific experiment. The keynote was titled: Carbon Language: An experimental successor to C++. But why do we need a successor and where did this idea come from?" Here we go again. Lynn |
| Muttley@dastardlyhq.com: Feb 28 08:38AM On Mon, 27 Feb 2023 18:31:35 +0100 >suspect you have never learned anything about serious programming, but >merely had a few courses in C and C++ - that would explain why you don't >understand basic concepts such as specifications. I've written C and C++ in aerospace including Misra C to SIL4 standard and even that doesn't spoon feed the developer to bounds check their array indexes as its a given than any half decent developer would do it where required. I've probably forgotten more about writing secure software than you ever knew but if being patronising makes you feel better then go for it. >and fix the bugs, but obsessing about pointless checks for one >particular type of potential bugs is no help to anyone. It's just an >excuse for not thinking and not paying attention to what you are doing. Whatever you say. I'm surprised you even post to a C++ group as why would you need the safety benefits of the language when clearly you're a master of unchecked accesses? Real programmers don't bounds check arrays or check for valid pointer values before they use them - just do a Nike, right? |
| "Öö Tiib" <ootiib@hot.ee>: Feb 28 01:33AM -0800 > need the safety benefits of the language when clearly you're a master of > unchecked accesses? Real programmers don't bounds check arrays or check for > valid pointer values before they use them - just do a Nike, right? It is not safety benefit that out of bounds access is undefined behavior. We have to use tools like valgrind, debug versions of standard library and sanitisers to catch bounds access errors during testing. However if everybody would start to write bounds check code to every place where array is accessed then that would turn the code into unreadable. Also what your code does when it realized that index that should not be out of bounds is out of bounds? Can't fix the bug run time. In other, checked languages the programming practice is very similar to that. They just get guaranteed exceptions or crashes always, not only on case of a debug tool being applied. For example if someone writes catch to ArrayIndexOutOfBoundsException in Java then review will question it ... was it for "safety"? Let it propagate and crash, can't fix programming errors run-time. Does program logic rely on that exception? Rethink that logic ... it is rather ugly. Similar in Swift. All array accesses return optional values there. Yet a guard block to detect that the result is not nil is rare as is passing the optional to others to suffer. Instead it will be typically immediately force-unwrapped with ! that crashes the program when optional is nil. Code will be full of those "potential crashes" yet hundreds of thousands users per month and app store reports zero crashes. |
| Muttley@dastardlyhq.com: Feb 28 10:17AM On Tue, 28 Feb 2023 01:33:15 -0800 (PST) >sanitisers to catch bounds access errors during testing. However if >everybody would start to write bounds check code to every place where >array is accessed then that would turn the code into unreadable. I'm not suggesting its done everywhere, but the majority of bugs in C programs are caused by out of bounds accesses either via arrays or pointers so its obviously not done enough, and with attitudes like Mr Browns claiming they never need to bother because their code is so perfect its hardly surprising. |
| "Öö Tiib" <ootiib@hot.ee>: Feb 28 02:43AM -0800 > are caused by out of bounds accesses either via arrays or pointers so its > obviously not done enough, and with attitudes like Mr Browns claiming they never > need to bother because their code is so perfect its hardly surprising. Yes, lot of bugs are because of out of bounds accesses. No, that does not indicate that code lacks checks. That indicates that unit tests are missing, testing is inadequate and/or that tools that I mentioned are not used. So bugs are not found and not fixed. Or otherwise let me reiterate: What your code does when it realized that index that should not be out of bounds is out of bounds? Can't fix the bug run time. |
| Malcolm McLean <malcolm.arthur.mclean@gmail.com>: Feb 28 03:19AM -0800 > I've written C and C++ in aerospace including Misra C to SIL4 standard and > even that doesn't spoon feed the developer to bounds check their array indexes > as its a given than any half decent developer would do it where required. It's a question of "defensive programming". With the code fragment void deleteentry(OBJECT *obj, int N, int index) { if (index >= 0 && index < N) /* do deletion */ } We suppress a crash if index is out of bounds. But that makes it harder to find the place where the index calculation goes wrong. So it's very debateable whether to keep the test in. |
| Richard Damon <Richard@Damon-Family.org>: Feb 28 08:10AM -0500 On 2/28/23 6:19 AM, Malcolm McLean wrote: > We suppress a crash if index is out of bounds. But that makes it harder to find the > place where the index calculation goes wrong. So it's very debateable whether to keep > the test in. Well, the answer to that is we should have an else clause that at minimum logs the error, and perhaps core dumps and ends. Of course, that is only appropriate if the function isn't supposed to be called with bad indexes. Sometimes the API is defined to be defensive, and "out of bounds" are considered "legal" and to be quietyl ignored, but, as you imply, that makes it harder to find errors that are creating the bad indexes. APIs that require the caller to be sure of the validity of the parameters lets us locate better where problems occur. That ALLOWS (but doesn't require) the adding of test code to recheck and core dump on errors, and then allows that removal for production. A properly written program will never envoke undefined behavior, so the unneeded checks aren't needed. But allowing them to be noisy helps get the program into that state of being properly written. APIs that require quiet ignoring just get in the way. |
| Malcolm McLean <malcolm.arthur.mclean@gmail.com>: Feb 28 05:42AM -0800 On Tuesday, 28 February 2023 at 13:10:46 UTC, Richard Damon wrote: > > the test in. > Well, the answer to that is we should have an else clause that at > minimum logs the error, and perhaps core dumps and ends. Generally you can't log the error, at least in a production setting. For example my code is ultimately released as a drawing package for artists. It's not acceptable to log an error, because that would generate calls to customer support which we wouldn't be able to handle effectively. That's quite common. In any sort of consumer / end user setting, it's not usually appropriate to involve the customer in debugging. |
| Richard Damon <Richard@Damon-Family.org>: Feb 28 09:39AM -0500 On 2/28/23 8:42 AM, Malcolm McLean wrote: > customer support which we wouldn't be able to handle effectively. That's > quite common. In any sort of consumer / end user setting, it's not usually > appropriate to involve the customer in debugging. No, you can still generally "log" the error, you just do it in a way that the customer can't normally see. You likely want the log to auto clear after some time, but then if the customer DOES have an issue and contacts support, they can do something to retrieve recent problem reports. Sort of like your car, there are lots of errors that might occur that get put into the internal log that don't bring up an "idiot" light, and at service time they can check for problems, or if a light does come on, they can look at the log to diagnose. |
| Malcolm McLean <malcolm.arthur.mclean@gmail.com>: Feb 28 07:12AM -0800 On Tuesday, 28 February 2023 at 14:39:37 UTC, Richard Damon wrote: > get put into the internal log that don't bring up an "idiot" light, and > at service time they can check for problems, or if a light does come on, > they can look at the log to diagnose. The decision to set up that sort of log is taken by the people who design the system, in that case probably the systems architect appointed by the automobile manufacturer. He might then provide an interface so that third party programmers can access the system and generate reports. But I can't really set up a logging system myself, in the absence of a package-wide system. We could make it work, of course, but it would be inappropriate. Though in fact we are in the process of developing a company wide logging system to log the usage patterns of our portions of the software. I couldn't untilaterally decide to extend or abuse that to log programming errors, however . In most programming, you are seldom working on a one man project where you are taking all the decisions yourself. |
| David Brown <david.brown@hesbynett.no>: Feb 28 04:37PM +0100 > I've written C and C++ in aerospace including Misra C to SIL4 standard and > even that doesn't spoon feed the developer to bounds check their array indexes > as its a given than any half decent developer would do it where required. I've done Misra and SIL too - and some of the rules involved are directly stupid and counter-productive. (Most are good.) For good quality, reliable hardware and software, following Misra and/or SIL reduces reliability. Much of it is just about arse-covering - saying you followed these rules so that you won't get sued if something else goes wrong. Blindly following rules - such as adding bounds checks for every array access - is just a small step above blind stupidity. Write the code correctly, and you won't be adding extra checks. You'll have checks where checks are useful because you are not sure of the validity of the data at that point. But re-checking data that you know is valid is simply /wrong/. It can be encouraged by lawyers, but that doesn't stop it making the software less reliable in total. (For some kinds of aerospace work you must take into account the possibility of unpredictable errors due to radiation and single-event upsets. Extra checks in software is, again, the wrong place to handle these - but sometimes it is not practical to handle them in the correct place with better hardware, ECC, redundancy, etc. Extra checks may then be better than nothing.) > I've probably forgotten more about writing secure software than you ever knew > but if being patronising makes you feel better then go for it. You have apparently forgotten the most important part. Make good, clear specifications for your code, and stick to them. In serious high reliability code, it is not unusual to /prove/ functions are correct according to the specifications - but you will at least expect comprehensive testing and code reviews. When the specifications for each function is correct, and each function follows the specifications, the complete system is correct. And it does not need extra pointless checks - they just hide problems, muddle the code, and make comprehensive system testing impossible. So if you want a function with the spec: // Function: small_power_of_ten // Inputs: uint32_t x, x >= 0, x <= 6 // Outputs: uint32_t y = 10 ^ x then you can implement it as: uint32_t small_power_of_ten(uint32_t x) { constexpr uint32_t powers[7] = { 1, 10, 100, 1000, 10000, 100000, 1000000 }; return powers[x]; } You should /not/ be adding an extra check for the array bounds in small_power_of_ten. You should be checking that any function that calls this one does so with a valid input. No function should ever call "small_power_of_ten" with a value above 6, because there is no specification for what will happen in such a case - that would clearly be a bug in the calling code. And if you think it would be more useful in your code to have a function that accepted a wider range of inputs, then you should specify it: // Function: small_power_of_ten_checked // Inputs: uint32_t x // Outputs: uint32_t y = 10 ^ x if x <= 6 // throws an exception if x > 6 That's a different function entirely. > need the safety benefits of the language when clearly you're a master of > unchecked accesses? Real programmers don't bounds check arrays or check for > valid pointer values before they use them - just do a Nike, right? You really do not understand, do you? In good code, there are no out-of-bounds accesses. But that is achieved by having code generate correct (and therefore valid) indices, not by checking them before use and trying to somehow magically have the called function fix the bug in the calling function. |
| David Brown <david.brown@hesbynett.no>: Feb 28 04:45PM +0100 On 28/02/2023 14:42, Malcolm McLean wrote: >>> We suppress a crash if index is out of bounds. But that makes it harder to find the >>> place where the index calculation goes wrong. So it's very debateable whether to keep >>> the test in. Indeed. You might have extra tests during testing and debugging phases, to help track errors. And sometimes you have no option but to release code that you don't know for sure is correct - programmers don't always get to decide on release plans. >> Well, the answer to that is we should have an else clause that at >> minimum logs the error, and perhaps core dumps and ends. > Generally you can't log the error, at least in a production setting. Generally, there is no "generally". There are endless varieties of what might be called a "production setting", with an almost endless variety of how to handle situations like this. > customer support which we wouldn't be able to handle effectively. That's > quite common. In any sort of consumer / end user setting, it's not usually > appropriate to involve the customer in debugging. Right, so it is better to let the customers continue to pay for and use buggy software than to learn about and fix the problems? That might be appropriate in some cases - and certainly I appreciate that it rarely helps to have lots of people report the same bug to customer support. |
| David Brown <david.brown@hesbynett.no>: Feb 28 04:50PM +0100 On 28/02/2023 11:43, Öö Tiib wrote: > bugs are not found and not fixed. Or otherwise let me reiterate: What your > code does when it realized that index that should not be out of bounds is > out of bounds? Can't fix the bug run time. Exactly. I have nothing against appropriate checks at the right places. I am against thoughtless and pointless checks that generally can't be tested, and can't do anything useful if the checks fail. The correct answer is to make sure the calling code is developed correctly. If you can't do that - perhaps the calling code is written by a different group - /then/ extra checks might be useful and you must specify how failures are handled (logs, crashes, hope for the best, email the developers' boss, etc.). Thus public API's for a high-level library can often include extra checks. Low-level code should not, except when it is a useful aid to debugging. |
| Muttley@dastardlyhq.com: Feb 28 03:56PM On Tue, 28 Feb 2023 16:37:57 +0100 >> as its a given than any half decent developer would do it where required. >I've done Misra and SIL too - and some of the rules involved are >directly stupid and counter-productive. (Most are good.) For good There are a few odd choices yes. >reduces reliability. Much of it is just about arse-covering - saying >you followed these rules so that you won't get sued if something else >goes wrong. Arse covering comes into it but a lot of it is very sensible. >possibility of unpredictable errors due to radiation and single-event >upsets. Extra checks in software is, again, the wrong place to handle If its a CPU register thats get zapped software is the only practical place to handle it. >comprehensive testing and code reviews. When the specifications for >each function is correct, and each function follows the specifications, >the complete system is correct. And it does not need extra pointless A function can follow specifications to the letter and still have hidden bugs. And if you make the specifications so in depth as to account for every eventuality then you end up debugging the specifications as well as the software. Something formal methods advocates tend to forget. >small_power_of_ten. You should be checking that any function that calls >this one does so with a valid input. No function should ever call >"small_power_of_ten" with a value above 6, because there is no And no one should ever steal either so I don't need a lock on my doors, right? >specification for what will happen in such a case - that would clearly >be a bug in the calling code. Its also a bug in your code in that it doesn't catch it. >You really do not understand, do you? I think I understand better than you. You seem to think complicated code can be provenly correct. It can't without a huge amount of time and effort and even then , its only as good as your spec in the first place. >by having code generate correct (and therefore valid) indices, not by >checking them before use and trying to somehow magically have the called >function fix the bug in the calling function. face <- palm |
| Richard Damon <Richard@Damon-Family.org>: Feb 28 11:29AM -0500 On 2/28/23 10:12 AM, Malcolm McLean wrote: > to extend or abuse that to log programming errors, however . > In most programming, you are seldom working on a one man project where you > are taking all the decisions yourself. But if you are working on a project, you are not a passive slave to that project, but can suggest improvements to the infrastructure. Yes, if the improvements are rejected, then it isn't your problem. I suppose that is the difference between a developer, and a coder. |
| "Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Feb 28 05:40PM +0100 > need the safety benefits of the language when clearly you're a master of > unchecked accesses? Real programmers don't bounds check arrays or check for > valid pointer values before they use them - just do a Nike, right? In case you're not just trolling, to get more background on the "no precondition check" view I recommend diving into Bertrand Meyer's classic book Object-Oriented Software Construction, in particular chapter 11 "Design by Contract: building reliable software" and chapter 12 "When the contract is broken: exception handling". With Eiffel (BM's own language) one can turn checking on or off, sort of like `assert`s in C++. The ideal BM argues for relies heavily on that and other language and tool support that just isn't there for C++ in general. However, there's are reasons why C++ is still popular and BM's newer more ideal language Eiffel never gained widespread popularity, and IMO a main one is that C++ is very much about dealing with an imperfect real world, including imperfect language and tool support. And that includes that not everything needs to be automated: with a little extra effort we can do without the conveniences of Eiffel, and then (with that little extra effort) "no checking" can be practical. - Alf Link: https://en.wikipedia.org/wiki/Object-Oriented_Software_Construction |
| David Brown <david.brown@hesbynett.no>: Feb 28 06:34PM +0100 >> upsets. Extra checks in software is, again, the wrong place to handle > If its a CPU register thats get zapped software is the only practical place to > handle it. You are joking, right? If there is a realistic possibility of cpu registers getting zapped, and the system is vital, you use redundant hardware. You use something like a PPC or Cortex-R device with dual lock-step processors, or some other external redundancy checking hardware. You don't cross your fingers and hope that the error happens to affect one register bit at one point in time, and that other register bits are not just as likely to be hit sooner or later. Remember, it is just as likely for the cpu register holding the index value to get hit just /after/ your check as just /before/ your check - or the register holding the array base could be hit, or the program counter, or anything else. Extra software checks can sometimes marginally improve your reliability, but only marginally - and it is usually /extremely/ difficult to quantify. >> the complete system is correct. And it does not need extra pointless > A function can follow specifications to the letter and still have hidden > bugs. The /specification/ can have bugs or be inappropriate in some way. The /hardware/ can have bugs. But if a piece of code gives the specified output and effects for the specified inputs, then it is correct and bug-free. > And if you make the specifications so in depth as to account for every > eventuality then you end up debugging the specifications as well as the > software. Something formal methods advocates tend to forget. You split things up into manageable pieces. And yes, you need to get the specifications right - that is also part of the job of software design. But again, you divide into parts and you divide the responsibilities (even if it is the same person doing everything). Get the specifications right for a function, then implement the function trusting the specifications. If you can't trust the specifications, you are not ready to code the function. >> this one does so with a valid input. No function should ever call >> "small_power_of_ten" with a value above 6, because there is no > And no one should ever steal either so I don't need a lock on my doors, right? You lock your front door, because that forms a boundary between areas of trust. You don't lock your in-house doors because you trust those inside the house. Check the parameters for calls from external source, not the inside ones. >> specification for what will happen in such a case - that would clearly >> be a bug in the calling code. > Its also a bug in your code in that it doesn't catch it. No, no, no. Establish your responsibilities and who is doing what task. The calling function must guarantee that it provides inputs according to the callee's specification. The callee assumes these are valid. It is not the callee's job to figure out what the caller did wrong - that would be impossible! (Again, as always, you might be able to provide some help during debugging.) > I think I understand better than you. You seem to think complicated code can > be provenly correct. It can't without a huge amount of time and effort and > even then , its only as good as your spec in the first place. Oh, I agree that code cannot be better than the specifications. And I agree that complicated code (or complicated specifications) make things much more difficult. That's why you divide things up into parts - both code and specifications - and handle them individually. That's why you don't waste time and effort making things needlessly extra complicated by duplicating effort or mixing work that is supposed to be done in the separate tasks. Let the caller do its job right, and let the callee trust its inputs - don't put the responsibility of getting the inputs right into the wrong task or function, or into /both/ tasks or functions. |
| Malcolm McLean <malcolm.arthur.mclean@gmail.com>: Feb 28 11:31AM -0800 On Tuesday, 28 February 2023 at 15:45:47 UTC, David Brown wrote: > buggy software than to learn about and fix the problems? That might be > appropriate in some cases - and certainly I appreciate that it rarely > helps to have lots of people report the same bug to customer support. We're a commercial company. Whilst of course we want to be honest, and we do want our software to be as good as possible, ultimately we're about making money. And customer support costs money. We offer good customer support for things that the support team can support, for example we can advise customers about their workflow and potentially save them very large amounts of artists' time, we can suggest tools which the customer has not found. But the support team can't fix bugs. They have to report bugs to the developers, who are us, and then a fix will cost at least a thousand pounds. Now the issue with logging errors isn't so much that the bug will be reported, as that the customer thinks he's done us a favour because he's dilgently noted down the error report and recorded it. So he expects a fix. And that will cost a thousand pounds. And if he doesn't get it, he'll think badly of us. And he knows if exactly the same bug crops up again, which might be after the "fix". A customer is a client, not a friend. You do try to be friendly and helpful. But ultimately his interests are not your interests. |
| David Brown <david.brown@hesbynett.no>: Feb 28 08:59PM +0100 On 28/02/2023 20:31, Malcolm McLean wrote: > same bug crops up again, which might be after the "fix". A customer > is a client, not a friend. You do try to be friendly and helpful. But > ultimately his interests are not your interests. Yes, I appreciate that, and it's fair enough - time and effort costs money. It just looked a little like you were hiding problems, to avoid customer services being bothered! |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment