Version: (using KDE 3.5.8) Installed from: SuSE RPMs Some checks for return codes are missing. Examples: Would you like to add more error handling for return values from "fseek" and "fread" like in the function "KMemoryWidget::fetchValues"? http://websvn.kde.org/trunk/KDE/kdebase/apps/kinfocenter/info/memory_sgi.cpp?revision=769694&view=markup
Hi, this type of technical discussion should be done on various mailing lists where developers can elaborate and choose how to manage this development hints. Thanks for your suggestions! Regards.
Hello FiNEX, I don't agree with you here and closing this bug as invalid isn't nice either. Instead of discussions, I'd love to see a proposed patch by the original bug reporter instead, esp. since he already wrote which functions should be checked for their return values. Since I don't have an SGI machine, he would probably be the best tester for patches anyway. Markus: If you read this, please reopen this bug and attach a proposed patch to this bug report. Regards, Helge
I agree with the "patches" part. Please reopen it if available!
(In reply to comment #2) > I don't agree with you here and closing this bug as invalid isn't nice either. Thanks for your accpetance. > Markus: If you read this, please reopen this bug and attach a proposed patch to > this bug report. I suggest to avoid unchecked function calls. Would we like to detect every error situation as early as possible? I could contribute a patch if the involved software design decisions would be clear (in a wider community). I would like to achieve consensus on acceptable approaches. 1. Would you like to reduce the efforts for error code checking by an exception class hierarchy? http://dietmar-kuehl.de/mirror/c++-faq/exceptions.html#faq-17.1 http://cexcept.sourceforge.net/ 2. Would you like to try aspect-orientation? http://en.wikipedia.org/wiki/Aspect-oriented_programming http://research.msrg.utoronto.ca/ACC/Tutorial#A_Reusable_Aspect_for_Memory_All 3. How do you think about to identify update candidates by compiler-specific extensions like the annotation "__attribute__ ((warn_unused_result))"? http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Function-Attributes.html
> I could contribute a patch if the involved software design decisions would be > clear (in a wider community). This is why I've suggested to use ML before.
Markus, what's wrong with normal, long-existing C style coding, e.g. error = fseek(xx,yy,..); if (error == -1) .... check errno if necessary ... I see no need at all to overdesign this.
(In reply to comment #6) > what's wrong with normal, long-existing C style coding, e.g. > > error = fseek(xx,yy,..); > if (error == -1) > .... check errno if necessary ... I would like to point out that such checking of return values can be extracted and encapsulated as a software design aspect in a separate source file.
Markus, if you like to discuss how software should be developed, which design technologies are available and such stuff, then I have to agree with FiNeX that it would be better to close this bug as WONTFIX and move any discussions to mailing lists. I'm happy that KDE does not has too much overdesign, and the coding in kinfocenter and related modules is straight-forward, clean and simple. I'm not interesting in changing this. Helge