| wij <wyniijj@gmail.com>: Jan 20 02:37AM -0800 On Wednesday, 19 January 2022 at 09:24:37 UTC+8, Lynn McGuire wrote: > effectively eliminate an entire class of runtime bugs by hoisting a > check into compile-time. Let's get right into it!" > Lynn The idea of using errno for error-handling (mandatory) had developed nearly 20 years ago and very successful. https://sourceforge.net/projects/cscall/files/latest/download It is about error checking, or inline test (programmers don't like this term). Coding syntax in this preliminary level may be too early (C++ is already burdensome , mostly developed from enthusiasm, ideal and insufficient experiences. The result might just be adding burdens, not 'feature', years latter). Hope the language developer may realize the issue of error-handling is the foundation of robust and efficient programs rather than syntax sugars. (Exception is not suitable for error-handling) |
| Juha Nieminen <nospam@thanks.invalid>: Jan 20 11:43AM > The idea of using errno for error-handling (mandatory) had developed > nearly 20 years ago and very successful. 'errno' alone may not be enough for error handling because sometimes you want or need more details about the error. Also, while not a show-stopper, 'errno' is easy to use wrong. Consider how easy it is to do something like this: if(!someFunction()) std::cerr << "Error calling someFunction(): " << std::strerror(errno); What's wrong with that? The fact that it's at least theoretically possible that that first operator<<() may change the value of errno (if it itself encounters some kind of error), in which case it's going to print the wrong error message. (This might be the reason for those infamous and hilarious "Error: No error" messages seen sometimes. It's not that there was no error, but that 'errno' (or whatever the program uses) was changed in between the actual error and showing the message.) (Sure, the proper way to handle this is to take the value of errno into a variable immediately after the function call, but consider how easy it's to do mistakes like the one above.) |
| Muttley@dastardlyhq.com: Jan 20 04:14PM On Thu, 20 Jan 2022 11:43:11 -0000 (UTC) >"Error: No error" messages seen sometimes. It's not that there was no >error, but that 'errno' (or whatever the program uses) was changed >in between the actual error and showing the message.) AFAIK the standard C library only sets errno if an error occurs. It never resets it to zero if there was no error. One would assume the C++ standard libraries behave the same way so "Error: no error" would only occur if the program has mistakenly seen a return value as a system error which would set errno when it might actually be a higher level error which doesn't. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jan 20 11:57AM -0500 On 1/20/22 6:43 AM, Juha Nieminen wrote: ... > "Error: No error" messages seen sometimes. It's not that there was no > error, but that 'errno' (or whatever the program uses) was changed > in between the actual error and showing the message.) When I've been in a position to check such things, I've usually found that they are the result of calling perror() without first checking whether errno was non-zero. When you use perror(), you should check to make sure under which circumstances the previously called function sets errno. Some things that are considered errors from the point of view of the developer do not actually result in errno being set. |
| wij <wyniijj@gmail.com>: Jan 20 09:06AM -0800 On Thursday, 20 January 2022 at 19:43:27 UTC+8, Juha Nieminen wrote: > (Sure, the proper way to handle this is to take the value of errno into > a variable immediately after the function call, but consider how easy > it's to do mistakes like the one above.) What programs need is a way to branch, errno is one basic way to do this. I use class Errno that contains only one int data member. class Errno { int m_errno; public: constexpr Errno(); constexpr Errno(const Errno&); ... }; My experience of using class Errno says errno (thread-local variable) could be an option if such impl. could be faster(and smaller). I did not recommend my implement but two points (debating such an issue might be unnecessarily long and fruitless). 1. Make error checking mandatory 2. Use __FILE__, __LINE__ to mark WHERE error detected. As I know, no programming language treats error-testing an essential part. Most programmers don't like to use and see error-testing(or handling) codes for each function call. But I found no way to escape, and my experience showed that explicit testing for errors and handling it in the end is 'efficient', at least for programmer's time (and thus money as well). Others are implementation problems. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Jan 20 05:14PM > As I know, no programming language treats error-testing an essential > part. You might want to take a look at Icon. It makes extensive (and very effective) use of the success and failure of even the most basic operations forstructuring the code. -- Ben. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jan 20 12:22PM -0500 > On Thu, 20 Jan 2022 11:43:11 -0000 (UTC) > Juha Nieminen <nospam@thanks.invalid> wrote: ... >> error, but that 'errno' (or whatever the program uses) was changed >> in between the actual error and showing the message.) > AFAIK the standard C library only sets errno if an error occurs. Oddly enough, that's not the case: "The value of errno in the initial thread is zero at program startup (the initial value of errno in other threads is an indeterminate value), but is never set to zero by any library function. 218) The value of errno may be set to nonzero by a library function call whether or not there is an error, provided the use of errno is not documented in the description of the function in this document." (C standard 7.5p3). Implicit in that statement is the fact that "provided the use of errno is ... documented in the description of the function in this document.", then that function may only use errno as specified by that documentation. > ... It never > resets it to zero if there was no error. As specified above, it never sets it to zero at all; that occurs only at program startup, and only for the initial thread. > libraries behave the same way so "Error: no error" would only occur if the > program has mistakenly seen a return value as a system error which would > set errno when it might actually be a higher level error which doesn't. The C++ standard prohibits the routines specified in <system_error>, from changing the value of errno (19.5p2). Otherwise, it never says anything to either mandate or prohibit changing errno. I would hope that what the C standard says about the use of errno by the C standard library can, by extension, be applied to the rest of the C++ standard library, but there's nothing that says so explicitly. |
| Andrey Tarasevich <andreytarasevich@hotmail.com>: Jan 20 09:35AM -0800 On 1/18/2022 5:24 PM, Lynn McGuire wrote: > post is not about how you can use it, but rather how we used it to > effectively eliminate an entire class of runtime bugs by hoisting a > check into compile-time. Let's get right into it!" What it basically boils down to is that C++20's `consteval` triggers a hard error for non-compile-time evaluations, as opposed to `constexpr`, which silently opted for run-time evaluation. -- Best regards, Andrey Tarasevich |
| Ian Collins <ian-news@hotmail.com>: Jan 21 08:50AM +1300 On 20/01/2022 23:37, wij wrote: > Hope the language developer may realize the issue of error-handling is the > foundation of robust and efficient programs rather than syntax sugars. > (Exception is not suitable for error-handling) So it's better to pick up the error at compile time, isn't it? The gcc and clang compilers have something similar for printf like logging with __attribute__ ((format (printf, FORMAT_ARG, VARG_BEGIN))) which has most likely saved many a run time error in similar situations. -- Ian. |
| legalize+jeeves@mail.xmission.com (Richard): Jan 20 10:19PM [Please do not mail me a copy of your followup] Lynn McGuire <lynnmcguire5@gmail.com> spake the secret code >"How we used C++20 to eliminate an entire class of runtime bugs" by >Cameron DaCamara >https://devblogs.microsoft.com/cppblog/how-we-used-cpp20-to-eliminate-an-entire-class-of-runtime-bugs/ Nice success story! -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| 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