Check return codes everywhere

what do you propose we do if fprintf(stderr, "......") fails?

a check for the malloc has been added.

1. Do you care for failed output and log messages?

2. How do you think about the reaction "exit(errno)" or "abort()"?

3. Can the tool "http://splint.org/" help to find any remaining issues?

4. 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/

Could you please respond to elfring's questions? Are there any other return codes that must be checked?

I'm not sure who DJ directed those questions at.

I'll put forward my opinion:

1. We don't care about fprintf failing.. It is unlikely to happen, and if it does - what are we going to do about it.. print a message?
2. exit() and abort() are to be avoided, but a fair response as a result of malloc failure
3. Possibly, but we don't have a lot of spare cycles for it. If you wanted to look at static analysis of the code-base, we'd be happy to incorporate any fixes that discovers.
4. I don't think so at this time. It is possible we may move to C++ at some point, and that may be up for rediscussion then, but for now I personally prefer to handle errors in the "old fashioned" way (or ignore them ;))

Currently our malloc strategy appears to be that it will succeed - or we will crash pretty quickly if NULL is returned. This is how glib encourages us to behave in the GTK HID, as g_malloc will exit if it fails.

Further to this - the developer mailing list is probably the best place to discuss things like this - keeping bug tickets for tangiable bugs or feature requests which can be closed when complete. If we keep bug tickets open to discuss general issues, we end up getting swamped in "bugs" we can never close.

> 3. If you wanted to look at static analysis of the code-base, we'd be happy to incorporate any fixes that discovers.

At some point I'll run Gimple's Lint over the code. Do you want a
thousand patches or one megalithic one against git head?
Maybe a sub-megalithic for example one that removes all unused
variables and functions (stuff that can never be reached in any way)?

Things that could reasonable be expected to fail, like memory
allocation, should test for error, and crash gracefully.
There should be some tangable message in a log or dialog that can be
reported to the bug tracker that aids in getting the problem fixed.
Don't be afraid to put in lots of __FILE__ and __LINE__ and where
supported __FUNCTION__. A wish request might be a tracing mechanism.

A Seg Fault with no explanation really shows our tools here in a very
poor light in commercial settings.
Boss's hear things like '#)$*#)* it crashed again' from the other side
of the cube farm if they are looking for a reason to disparage Open
Source.

--
http://blog.softwaresafety.net/
http://www.designer-iii.com/
http://www.wearablesmartsensors.com/

1. I suggest to call the function "exit(errno)" or "abort()" (if a try for an error message output failed).
   Would you like to replace any calls for the function "fprintf" by "g_log"?
   http://library.gnome.org/devel/glib/stable/glib-Message-Logging.html#g-logv

4. How do you think about informations from the article "Quality Matters #6: Exceptions for Practically-Unrecoverable Conditions" by Matthew Wilson?
   http://accu.org/index.php/journals/1706/

5. How do you think about to apply aspect-oriented software development?
   http://aspectc.org/
   http://research.msrg.utoronto.ca/ACC/Tutorial#A_Reusable_Aspect_for_Memory_All

I haven't got any time to follow up on this now.

Like I said earlier, I think this is wrong forum to discuss this. We of course welcome input if you want to submit patches for the project.

Regards patches, logically contained patches are nice, but that might include removing a whole class of errors. There should not be any unused variables.. I went through and made sure PCB compile without warnings recently.

With regards __FILE__ etc.. I've seen a nice way to do this. For example:

#define malloc(x) _malloc(x, __FILE__, __FUNCTION__)

Then define a function

void *malloc (size_t size, const char *file, const char *function)
{
  void *ptr = malloc (size);
  if (ptr == NULL) {
    fprintf (stderr, ".... %s %s", file, function);
    abort ();
  }
  return ptr;
}

On Sat, Jan 15, 2011 at 11:30 AM, Peter Clifton <email address hidden> wrote:
> I haven't got any time to follow up on this now.

How discouraging.

> Like I said earlier, I think this is wrong forum to discuss this.

Where is the correct place to discuss such things? gEDA-Users isn't,
and gEDA-Development is not allowed.
For example __FUNCTION__ is not portable across compilers.

-Werror should be added to configure.ac, I'll make a patch and submit
it, as there are still several warnings with the current GIT head.

# if we have gcc then add -Wall and -Werror
if test "x$GCC" = "xyes"; then
 # see about adding some extra checks if the compiler takes them
 for flag in -Wall -Werror -Wdeclaration-after-statement ; do

That is why the #define is useful - you can write the macro and change it depending on the compiler / platform.

A -Werror will be rejected I think. I did it before for gEDA, and got told to revert it. Different gcc versions will hit different warnings, and it was deemed a bit cruel to break people's builds if gcc introduces a new warning we happen to trigger.

The problem I have with this bug is that it is at best a "meta-bug". (Not so much the original issue, but the way it has gone). There seems to be little point keeping bug tracker items open for the sake of general discussion about a non-problem.

Feel free to request geda-dev list access from Ales if you want to discuss development.

[Expired for pcb because there has been no activity for 60 days.]

("incomplete" is for bugs waiting on bug reporter input, Launchpad closes such bugs automatically after some time)