{"thread":{"id":"22485","subject":"Completion of error handling","startedAt":"2010-02-02T13:11:59Z","lastAt":"2010-02-18T15:11:03Z","messageCount":14,"participants":["Markus Elfring","Nicolas Pitre","Avery Pennarun","Andreas Ericsson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"133351","messageId":"4B68249F.6070004@web.de","threadId":"22485","inReplyTo":null,"subject":"Completion of error handling","fromName":"Markus Elfring","fromEmail":"markus.elfring@web.de","sentAt":"2010-02-02T13:11:59Z","receivedAt":"2010-02-02T13:11:59Z","isPatch":false,"sender":{"key":"markus.elfring@web.de","avatar":null},"body":"Hello,\n\nI would like to point out that some checks for return codes are missing in the source files.\n\nExamples:\nWould you like to add more error handling for return values from \"pthread_mutex_init\" like in the function \"start_threads\" and from \"fprintf\" in the function \"output_header_lines\"?\nhttp://git.kernel.org/?p=git/git.git;a=blob;f=builtin-grep.c;h=0ef849cb84650705ffc840aed8a3fcedbeb48f9a;hb=HEAD#l224\nhttp://git.kernel.org/?p=git/git.git;a=blob;f=builtin-mailinfo.c;h=a50ac2256cdbacd76ed44a50804212be07f949db;hb=HEAD#l935\n\nRegards,\nMarkus\n"},{"id":"133373","messageId":"alpine.LFD.2.00.1002021324290.1681@xanadu.home","threadId":"22485","inReplyTo":"4B68249F.6070004@web.de","subject":"Re: Completion of error handling","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-02-02T18:26:27Z","receivedAt":"2010-02-02T18:26:27Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 2 Feb 2010, Markus Elfring wrote:\n\n> Hello,\n> \n> I would like to point out that some checks for return codes are missing in the source files.\n> \n> Examples:\n> Would you like to add more error handling for return values from \"pthread_mutex_init\" like in the function \"start_threads\" and from \"fprintf\" in the function \"output_header_lines\"?\n\nWhat is the likelihood for those function calls to actually fail?\n\n\nNicolas\n"},{"id":"133374","messageId":"4B6873AC.4030303@web.de","threadId":"22485","inReplyTo":"alpine.LFD.2.00.1002021324290.1681@xanadu.home","subject":"Re: Completion of error handling","fromName":"Markus Elfring","fromEmail":"markus.elfring@web.de","sentAt":"2010-02-02T18:49:16Z","receivedAt":"2010-02-02T18:49:16Z","isPatch":false,"sender":{"key":"markus.elfring@web.de","avatar":null},"body":"\n> What is the likelihood for those function calls to actually fail?\n\nDo you know the probability for failed memory allocations?\n\nWould you like to care for error codes from all Pthread function calls?\n\nRegards,\nMarkus\n"},{"id":"133378","messageId":"alpine.LFD.2.00.1002021424550.1681@xanadu.home","threadId":"22485","inReplyTo":"4B6873AC.4030303@web.de","subject":"Re: Completion of error handling","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-02-02T19:27:28Z","receivedAt":"2010-02-02T19:27:28Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 2 Feb 2010, Markus Elfring wrote:\n\n> \n> > What is the likelihood for those function calls to actually fail?\n> \n> Do you know the probability for failed memory allocations?\n> \n> Would you like to care for error codes from all Pthread function calls?\n\nNot necessarily. At least on Linux, most of those functions simply \ncannot fail. There is just no dynamic memory allocation involved. All \nother errors are normally due to bad code.\n\n\nNicolas\n"},{"id":"133379","messageId":"4B688042.8090400@web.de","threadId":"22485","inReplyTo":"alpine.LFD.2.00.1002021424550.1681@xanadu.home","subject":"Re: Completion of error handling","fromName":"Markus Elfring","fromEmail":"markus.elfring@web.de","sentAt":"2010-02-02T19:42:58Z","receivedAt":"2010-02-02T19:42:58Z","isPatch":false,"sender":{"key":"markus.elfring@web.de","avatar":null},"body":"\n> At least on Linux, most of those functions simply cannot fail.\n\nWould you like to support software environments that work without a\nfamous out-of-memory killer?\n\n\n> There is just no dynamic memory allocation involved.\n> \n\nI find this opinion strange.\n\n\n> All other errors are normally due to bad code.\n> \n\nI suggest to avoid unchecked function calls.\nWould you like to detect every error situation as early as possible?\n\nRegards,\nMarkus\n"},{"id":"133381","messageId":"32541b131002021149g6ffe703erd9e25621e4305a52@mail.gmail.com","threadId":"22485","inReplyTo":"4B688042.8090400@web.de","subject":"Re: Completion of error handling","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-02-02T19:49:31Z","receivedAt":"2010-02-02T19:49:31Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Tue, Feb 2, 2010 at 2:42 PM, Markus Elfring wrote:\n> Nicolas wrote:\n>> At least on Linux, most of those functions simply cannot fail.\n>\n> Would you like to support software environments that work without a\n> famous out-of-memory killer?\n\nIn many cases on Linux systems, you don't get the OOM notification\nanyway until you try to *use* the memory, not at allocation time. So\neven checking the results of malloc() won't always save you (although\n*not* checking can make problems even worse).\n\nHowever, for functions that can't allocate memory at all, it's extra\npointless to worry about.\n\n>> There is just no dynamic memory allocation involved.\n>\n> I find this opinion strange.\n\nThis isn't an opinion; because it's open source, you can actually look\nat the source code and find out that many system calls don't do memory\nallocation at all.\n\nAvery\n"},{"id":"133385","messageId":"4B6886CE.9040602@web.de","threadId":"22485","inReplyTo":"32541b131002021149g6ffe703erd9e25621e4305a52@mail.gmail.com","subject":"Re: Completion of error handling","fromName":"Markus Elfring","fromEmail":"markus.elfring@web.de","sentAt":"2010-02-02T20:10:54Z","receivedAt":"2010-02-02T20:10:54Z","isPatch":false,"sender":{"key":"markus.elfring@web.de","avatar":null},"body":"\n>\n> This isn't an opinion; because it's open source, you can actually look\n> at the source code and find out that many system calls don't do memory\n> allocation at all.\n> \n\nI agree to your view because you distinguish between the available\nsoftware implementations here.\nAre you also interested to complete error detection and corresponding\nexception handling?\n\nRegards,\nMarkus\n"},{"id":"133386","messageId":"32541b131002021225k19ef94b2me8ef40cd502b85d@mail.gmail.com","threadId":"22485","inReplyTo":"4B6886CE.9040602@web.de","subject":"Re: Completion of error handling","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-02-02T20:25:05Z","receivedAt":"2010-02-02T20:25:05Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Tue, Feb 2, 2010 at 3:10 PM, Markus Elfring wrote:\n>> This isn't an opinion; because it's open source, you can actually look\n>> at the source code and find out that many system calls don't do memory\n>> allocation at all.\n>\n> I agree to your view because you distinguish between the available\n> software implementations here.\n> Are you also interested to complete error detection and corresponding\n> exception handling?\n\nI think if you can demonstrate actual situations where lack of error\nhandling could cause:\na) user confusion; or\nb) data loss/corruption\n\n...then it will be easy to get people to accept your patches to fix\nthe error handling. If you can't reproduce or at least describe such\na case in detail, however, people probably won't be too excited about\nit. git developers seem to concentrate more on concrete problems than\ntheoretical ones.\n\nAvery\n"},{"id":"133395","messageId":"4B68989D.80906@web.de","threadId":"22485","inReplyTo":"32541b131002021225k19ef94b2me8ef40cd502b85d@mail.gmail.com","subject":"Re: Completion of error handling","fromName":"Markus Elfring","fromEmail":"markus.elfring@web.de","sentAt":"2010-02-02T21:26:53Z","receivedAt":"2010-02-02T21:26:53Z","isPatch":false,"sender":{"key":"markus.elfring@web.de","avatar":null},"body":"\n>\n> ...then it will be easy to get people to accept your patches to fix\n> the error handling.\n> \n\nYou do not need to make assumptions about error situations. Please check\nall error codes.\nOtherwise, it might not be noticed if anything unexpected went wrong.\n\nRegards,\nMarkus\n"},{"id":"133396","messageId":"32541b131002021327u29e666b8ia5c6aab25fb55688@mail.gmail.com","threadId":"22485","inReplyTo":"4B68989D.80906@web.de","subject":"Re: Completion of error handling","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-02-02T21:27:29Z","receivedAt":"2010-02-02T21:27:29Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Tue, Feb 2, 2010 at 4:26 PM, Markus Elfring wrote:\n>> ...then it will be easy to get people to accept your patches to fix\n>> the error handling.\n>\n> You do not need to make assumptions about error situations. Please check\n> all error codes.\n> Otherwise, it might not be noticed if anything unexpected went wrong.\n\nIf you never notice, then that's a good thing, right? :)\n\nAvery\n"},{"id":"133398","messageId":"4B689F37.1030701@web.de","threadId":"22485","inReplyTo":"32541b131002021327u29e666b8ia5c6aab25fb55688@mail.gmail.com","subject":"Re: Completion of error handling","fromName":"Markus Elfring","fromEmail":"markus.elfring@web.de","sentAt":"2010-02-02T21:55:03Z","receivedAt":"2010-02-02T21:55:03Z","isPatch":false,"sender":{"key":"markus.elfring@web.de","avatar":null},"body":"\n>\n> If you never notice, then that's a good thing, right? :)\n> \n\nWell, this depends on the kind of potential damage that will come from\nthe ignorance of function return values.\nIt might hurt more when corresponding effects can not be ignorable any\nmore because they became so obvious.\n\nRegards,\nMarkus\n"},{"id":"134220","messageId":"4B740153.4010600@web.de","threadId":"22485","inReplyTo":"alpine.LFD.2.00.1002021324290.1681@xanadu.home","subject":"Re: Completion of error handling","fromName":"Markus Elfring","fromEmail":"markus.elfring@web.de","sentAt":"2010-02-11T13:08:35Z","receivedAt":"2010-02-11T13:08:35Z","isPatch":false,"sender":{"key":"markus.elfring@web.de","avatar":null},"body":"\n>\n> What is the likelihood for those function calls to actually fail?\n> \n\nHow do you think about the usual design choices that are described in\nthe article \"Exception Handling Alternatives\" by Detlef Vollmann.\nhttp://accu.org/index.php/journals/546\n\n\nI propose to write pointcuts for all functions that can return values.\nSome corresponding error codes are checked already. But there a places\nin the source files with open issues for complete software robustness.\n\nAre there any chances to encapsulate more cross-cutting concerns as\nreusable aspects?\n\nWould you like to integrate tools like the following into your software\ndevelopment process?\n- AspectC++\n http://aspectc.org/\n\n- ACC\n \nhttp://research.msrg.utoronto.ca/ACC/Tutorial#A_Reusable_Aspect_for_Memory_All\n\n- Coccinelle\n http://coccinelle.lip6.fr/\n\nRegards,\nMarkus\n"},{"id":"134726","messageId":"4B7A79F0.1070100@op5.se","threadId":"22485","inReplyTo":"4B740153.4010600@web.de","subject":"Re: Completion of error handling","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2010-02-16T10:56:48Z","receivedAt":"2010-02-16T10:56:48Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 02/11/2010 02:08 PM, Markus Elfring wrote:\n> \n>>\n>> What is the likelihood for those function calls to actually fail?\n>>\n> \n> How do you think about the usual design choices that are described in\n> the article \"Exception Handling Alternatives\" by Detlef Vollmann.\n> http://accu.org/index.php/journals/546\n> \n\nThat's an awful lot of text to read that's hardly relevant for a C\nprogram. Most of it regards newbie stuff about how to handle reporting\nan error when you can't use a C++ exception.\n\n> \n> I propose to write pointcuts for all functions that can return values.\n> Some corresponding error codes are checked already. But there a places\n> in the source files with open issues for complete software robustness.\n> \n\nYou keep on claiming that but haven't proven it in any way. If you\ncould point out a real bug I'm very, very certain it would be fixed\nwithin 24 hours.\n\n> Are there any chances to encapsulate more cross-cutting concerns as\n> reusable aspects?\n> \n> Would you like to integrate tools like the following into your software\n> development process?\n> - AspectC++\n> http://aspectc.org/\n> \n\nGit is written in C, not C++. Using aspectc++ would mean requiring\nthe use of a C++ compiler, which git doesn't require today. That's\none step backwards in portability which I seriously doubt the\nusefulness of aspectc++ can outweigh.\n\nNow please stop trolling and find one of these bugs you keep talking\nabout but never showing. We've made it painfully clear to you that\nwe're interested in realworld problems rather than potential ones,\nso all this \"use this model for development\" just reeks of concept\nevangelism. No real engineer likes that, which is why you're facing\nsuch massive opposition on this list.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"134974","messageId":"4B7D5887.6050502@web.de","threadId":"22485","inReplyTo":"4B7A79F0.1070100@op5.se","subject":"Re: Completion of error handling","fromName":"Markus Elfring","fromEmail":"markus.elfring@web.de","sentAt":"2010-02-18T15:11:03Z","receivedAt":"2010-02-18T15:11:03Z","isPatch":false,"sender":{"key":"markus.elfring@web.de","avatar":null},"body":"\n> That's an awful lot of text to read that's hardly relevant for a C\n> program. Most of it regards newbie stuff about how to handle reporting\n> an error when you can't use a C++ exception.\n> \n\nI would like to quote a bit which shows the underlying issues with the\nused programming language.\n\"...\nExceptional events occur. But, since they are exceptional, they occur\nvery rarely. This is exactly the problem with them. In programming\ncourses you learn to always handle any possible event. But, in practice,\nmost programmers just ignore them. If you look at this problem in\ndetail, you see that these events are not ignored where they actually\noccur, but at some higher level.\n...\"\n\n\n>\n> You keep on claiming that but haven't proven it in any way.\n\nI do not want to prove this so far because return value ignorance might\nbe a common and well-known (bad) coding practice.\nhttps://www.securecoding.cert.org/confluence/display/seccode/EXP12-C.+Do+not+ignore+values+returned+by+functions\n\n\n>\n> Git is written in C, not C++. Using aspectc++ would mean requiring\n> the use of a C++ compiler, which git doesn't require today.\n\nIt would be nice if C++ exceptions could be used here because they can\nnot be ignored by default. I guess that the tool \"AspectC++\" will also\nwork with C constructs. Do you find the tool \"AspeCt-oriented C\ncompiler\" more appealing?\n\n\n> Now please stop trolling and find one of these bugs you keep talking\n> about but never showing.\n\nI would not say never. - Exceptional situations are usually expected to\nappear seldom.\n\n\n> We've made it painfully clear to you that we're interested in realworld\n> problems rather than potential ones, so all this \"use this model for\n> development\" just reeks of concept evangelism.\n\nThe efforts for complete error code checking can be reduced by a mixture\nof function, class and advice libraries.\n\n\n> No real engineer likes that, which is why you're facing\n> such massive opposition on this list.\n> \n\nIt takes a bit more time to become comfortable with evolving software\ntechnologies.\n\nRegards,\nMarkus\n"}]}