[PATCH] lib: libfile: Do not ignore errors in close()

[PATCH] lib: libfile: Do not ignore errors in close()

[Andrey Smirnov]

From: Andrey Smirnov <andrew.smirnov@gmail.com>

Some character devices may perform meaningful operations in their
implementation of close() -- a good example would be socfpga.c which
checks if the FPGA was programmed succesfully in it's close() method
-- so ignoring return value of this call may cause false positives in
checking exit status for success.

Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
 lib/libfile.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/libfile.c b/lib/libfile.c
index 8acff04..4f21e70 100644
--- a/lib/libfile.c
+++ b/lib/libfile.c
@@ -262,7 +262,7 @@ int copy_file(const char *src, const char *dst, int verbose)
 	char *rw_buf = NULL;
 	int srcfd = 0, dstfd = 0;
 	int r, w;
-	int ret = 1;
+	int ret = 1, err1 = 0, err2 = 0;
 	void *buf;
 	int total = 0;
 	struct stat statbuf;
@@ -324,11 +324,11 @@ out:
 
 	free(rw_buf);
 	if (srcfd > 0)
-		close(srcfd);
+		err1 = close(srcfd);
 	if (dstfd > 0)
-		close(dstfd);
+		err2 = close(dstfd);
 
-	return ret;
+	return ret ?: err1 ?: err2;
 }
 EXPORT_SYMBOL(copy_file);
 
-- 
2.1.4


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH] lib: libfile: Do not ignore errors in close()

[Sascha Hauer]

On Sun, Jul 12, 2015 at 05:09:47PM -0700, Andrey Smirnov wrote:
> From: Andrey Smirnov <andrew.smirnov@gmail.com>
> 
> Some character devices may perform meaningful operations in their
> implementation of close() -- a good example would be socfpga.c which
> checks if the FPGA was programmed succesfully in it's close() method
> -- so ignoring return value of this call may cause false positives in
> checking exit status for success.
> 
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> ---
>  lib/libfile.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/lib/libfile.c b/lib/libfile.c
> index 8acff04..4f21e70 100644
> --- a/lib/libfile.c
> +++ b/lib/libfile.c
> @@ -262,7 +262,7 @@ int copy_file(const char *src, const char *dst, int verbose)
>  	char *rw_buf = NULL;
>  	int srcfd = 0, dstfd = 0;
>  	int r, w;
> -	int ret = 1;
> +	int ret = 1, err1 = 0, err2 = 0;
>  	void *buf;
>  	int total = 0;
>  	struct stat statbuf;
> @@ -324,11 +324,11 @@ out:
>  
>  	free(rw_buf);
>  	if (srcfd > 0)
> -		close(srcfd);
> +		err1 = close(srcfd);
>  	if (dstfd > 0)
> -		close(dstfd);
> +		err2 = close(dstfd);

I agree that an error on closing the destination is an error for
copy_file, but is an error on closing the source file an error for
copy_file? We read everything from the source, so errors while closing
the file should not be relevant.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH] lib: libfile: Do not ignore errors in close()

[Andrey Smirnov]

>>       free(rw_buf);
>>       if (srcfd > 0)
>> -             close(srcfd);
>> +             err1 = close(srcfd);
>>       if (dstfd > 0)
>> -             close(dstfd);
>> +             err2 = close(dstfd);
>
> I agree that an error on closing the destination is an error for
> copy_file, but is an error on closing the source file an error for
> copy_file? We read everything from the source, so errors while closing
> the file should not be relevant.

I guess it depends on one's interpretation of what "success" means for
execution of copy_file(). I personally interpret it as: "the function
accomplished what is was supposed to do and all of the operations that
had to be done in order to do that completed without any errors", but
I can see how that being defined as "the function accomplished it's
main purpose with some possible minor failures" could work too. Since
I expect a call to close() to not fail for 99% of the time I don't see
any harm in checking for errors from both calls, but I don't feel very
strongly about the subject so if you want it I can remove the extra
check.

Andrey

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox