GNU bug report logs - #11058
Completion of error handling

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 11058 in the body.
You can then email your comments to 11058 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Markus Elfring <Markus.Elfring <at> web.de>
To: bug-coreutils <at> gnu.org
Subject: Completion of error handling
Date: Wed, 21 Mar 2012 22:50:18 +0100

Hello!

I have looked at a few source files for your current software. I have 
noticed that some checks for return codes are missing.

Would you like to add more error handling for return values from 
functions like the following?
- atexit ⇒ main

http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/date.c?id=3ba8b044267a5f7cfa8a7b0d7f19dab3f21431da#n320

- fputs ⇒ print_numbers

http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/seq.c?id=d3227eeb90c8308abd1e6bf08ee253b7a4e78d1d#n238

- printf ⇒ write_header

http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/head.c?id=d7878454cd02518959b0d6036db3a5b6ff00ca57#n162

Regards,
Markus

Message #12 received at 11058-done <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Markus Elfring <Markus.Elfring <at> web.de>
Cc: 11058-done <at> debbugs.gnu.org
Subject: Re: bug#11058: Completion of error handling
Date: Wed, 21 Mar 2012 16:13:34 -0600

[Message part 1 (text/plain, inline)]

tag 11058 notabug
thanks

On 03/21/2012 03:50 PM, Markus Elfring wrote:
> Hello!
> 
> I have looked at a few source files for your current software. I have
> noticed that some checks for return codes are missing.

Thanks for the report.

> 
> Would you like to add more error handling for return values from
> functions like the following?
> - atexit ⇒ main
> 
> http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/date.c?id=3ba8b044267a5f7cfa8a7b0d7f19dab3f21431da#n320

Maybe worth cleaning up all atexit() calls, but unlikely to ever fail
since POSIX guarantees at least 32 successful atexit calls and we are
only making 1.  I'm not losing any sleep if we don't change this.

> 
> - fputs ⇒ print_numbers
> 
> http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/seq.c?id=d3227eeb90c8308abd1e6bf08ee253b7a4e78d1d#n238
> 
> 
> - printf ⇒ write_header
> 
> http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/head.c?id=d7878454cd02518959b0d6036db3a5b6ff00ca57#n162

Intentional.  We have chosen to instead install an atexit handler as
well as use the gnulib module close-stream, which guarantees that we
investigate ferror() for all closed FILE*, and deal with the errors in a
central location rather than bloating the code to deal with errors after
every single operation on a FILE*.  Not worth your time to try to patch
these.

You can still submit patches, and we will still evaluate them on their
individual merits, but I don't see this as fixing any actual bugs at the
moment, so I'm marking this bug as closed.

-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #13 received at 11058-done <at> debbugs.gnu.org (full text, mbox):

From: Markus Elfring <Markus.Elfring <at> web.de>
To: Eric Blake <eblake <at> redhat.com>
Cc: 11058-done <at> debbugs.gnu.org
Subject: Re: bug#11058: Completion of error handling
Date: Thu, 22 Mar 2012 11:01:13 +0100

> Intentional.  We have chosen to instead install an atexit handler as
> well as use the gnulib module close-stream, which guarantees that we
> investigate ferror() for all closed FILE*, and deal with the errors in a
> central location rather than bloating the code to deal with errors after
> every single operation on a FILE*.

How do the affected programs behave if the output target will be 
connected to a full device?

I suggest to avoid unchecked function calls.
Would you like to detect every error situation as early as possible?

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

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

Regards,
Markus

Message #14 received at 11058-done <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Markus Elfring <Markus.Elfring <at> web.de>
Cc: 11058-done <at> debbugs.gnu.org
Subject: Re: bug#11058: Completion of error handling
Date: Thu, 22 Mar 2012 04:58:29 -0600

[Message part 1 (text/plain, inline)]

On 03/22/2012 04:01 AM, Markus Elfring wrote:
>> Intentional.  We have chosen to instead install an atexit handler as
>> well as use the gnulib module close-stream, which guarantees that we
>> investigate ferror() for all closed FILE*, and deal with the errors in a
>> central location rather than bloating the code to deal with errors after
>> every single operation on a FILE*.
> 
> How do the affected programs behave if the output target will be
> connected to a full device?

The program reports the error and exits with non-zero status.  And 'make
check' ensures this.  See, for example, tests/misc/help-version, which
explicitly calls 'program --help >/dev/full' to check that the write
errors are detected, even though we intentionally didn't bother to check
each fprintf or fputs during usage(), but instead only check at the
point of fclose.

> 
> I suggest to avoid unchecked function calls.

We agree on that principle, but our practice of that is done by checking
at the fclose rather than cluttering the rest of the code with redundant
checks.

> Would you like to detect every error situation as early as possible?

Not if it is a maintenance nightmare.

> 
> 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
> 
> 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

You're welcome to submit patches, and we will evaluate them on their
merits, if you think the current code base is wrong.  But I'm perfectly
happy with our current coding style.

-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #15 received at 11058-done <at> debbugs.gnu.org (full text, mbox):

From: Markus Elfring <Markus.Elfring <at> web.de>
To: Eric Blake <eblake <at> redhat.com>
Cc: 11058-done <at> debbugs.gnu.org
Subject: Re: bug#11058: Completion of error handling
Date: Thu, 22 Mar 2012 12:13:53 +0100

> We agree on that principle, but our practice of that is done
> by checking at the fclose rather than cluttering the rest of the code
> with redundant checks.

Thanks for your clarification.


> Not if it is a maintenance nightmare.

How do you think about to ecapsulate error detection as reusable aspects?


> You're welcome to submit patches, and we will evaluate them on their
> merits, if you think the current code base is wrong.

How are the chances to cooperate with a tool like "AspectC++"?

Regards,
Markus

Message #16 received at 11058-done <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Markus Elfring <Markus.Elfring <at> web.de>
Cc: 11058-done <at> debbugs.gnu.org
Subject: Re: bug#11058: Completion of error handling
Date: Thu, 22 Mar 2012 05:18:16 -0600

[Message part 1 (text/plain, inline)]

On 03/22/2012 05:13 AM, Markus Elfring wrote:
>> Not if it is a maintenance nightmare.
> 
> How do you think about to ecapsulate error detection as reusable aspects?

Submit a patch, and we'll evaluate it.

>> You're welcome to submit patches, and we will evaluate them on their
>> merits, if you think the current code base is wrong.
> 
> How are the chances to cooperate with a tool like "AspectC++"?

Coreutils is written in C, not C++, so I'm not sure how a tool like
AspectC++ would be usable.  But without knowing the tool, and without a
patch showing how the tool might be useful, I can't offer any further
opinion.  The current code base doesn't bother me, so the burden is now
on you to demonstrate that refactoring the code base to work with a new
tool has a payoff of easier maintenance (that is, that such a tool could
avoid errors by making auditing easier, provided we abide by the
guidelines expected by such a tool).

-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #17 received at 11058-done <at> debbugs.gnu.org (full text, mbox):

From: Markus Elfring <Markus.Elfring <at> web.de>
To: Eric Blake <eblake <at> redhat.com>
Cc: 11058-done <at> debbugs.gnu.org
Subject: Re: bug#11058: Completion of error handling
Date: Thu, 22 Mar 2012 13:30:31 +0100

> Submit a patch, and we'll evaluate it.

I hope that the involved technical details can be clarified before the 
potential review of a concrete patch.


> Coreutils is written in C, not C++, so I'm not sure how a tool like
> AspectC++ would be usable.

Aspects are another evolving means to structure some source code.


> But without knowing the tool, and without a patch showing how the tool
> might be useful, I can't offer any further opinion.

I guess that you will be able to decide on related software design 
decisions. It is a matter if the introduction of a dependency on a 
dedicated tool will become generally acceptable.


> The current code base doesn't bother me, so the burden is now on you
> to demonstrate that refactoring the code base to work with a new tool
> has a payoff of easier maintenance (that is, that such a tool could
> avoid errors by making auditing easier, provided we abide by the guidelines
> expected by such a tool).

Other software developers and computer scientists have already 
demonstrated the usefulness of aspect-oriented software development.
http://research.msrg.utoronto.ca/ACC/Tutorial
http://aspectc.org/Publications.6.0.html
http://aosd.net/

I would like to find out if corresponding techniques will also become 
applicable for your source files.

Regards,
Markus

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.