leandrof/linux
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

CodingStyle: Clarify and complete chapter 7

Browse Source 
Chapter 7 (Centralized exiting of functions) of the coding style
documentation is unclear at times, and lacks some information (such
as the possibility to indent labels with a single space.) Clarify and
complete it.

Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Markus Elfring <elfring@users.sourceforge.net>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
Jean Delvare 2016-07-25 14:29:06 +02:00 committed by Jonathan Corbet
parent 35db7e94cd
commit 865a1caa4b
1 changed files with 19 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
Documentation/CodingStyle
View File

@ -396,9 +396,13 @@ locations and some common work such as cleanup has to be done. If there is no
cleanup needed then just return directly. cleanup needed then just return directly.
Choose label names which say what the goto does or why the goto exists. An Choose label names which say what the goto does or why the goto exists. An
example of a good name could be "out_buffer:" if the goto frees "buffer". Avoid example of a good name could be "out_free_buffer:" if the goto frees "buffer".
using GW-BASIC names like "err1:" and "err2:". Also don't name them after the Avoid using GW-BASIC names like "err1:" and "err2:", as you would have to
goto location like "err_kmalloc_failed:" renumber them if you ever add or remove exit paths, and they make correctness
difficult to verify anyway.
It is advised to indent labels with a single space (not tab), so that
"diff -p" does not confuse labels with functions.
The rationale for using gotos is: The rationale for using gotos is:
@ -425,20 +429,29 @@ The rationale for using gotos is:
goto out_buffer; goto out_buffer;
} }
... ...
out_buffer: out_free_buffer:
kfree(buffer); kfree(buffer);
return result; return result;
} }
A common type of bug to be aware of is "one err bugs" which look like this: A common type of bug to be aware of is "one err bugs" which look like this:
err: err:
kfree(foo->bar); kfree(foo->bar);
kfree(foo); kfree(foo);
return ret; return ret;
The bug in this code is that on some exit paths "foo" is NULL. Normally the The bug in this code is that on some exit paths "foo" is NULL. Normally the
fix for this is to split it up into two error labels "err_bar:" and "err_foo:". fix for this is to split it up into two error labels "err_free_bar:" and
"err_free_foo:":
err_free_bar:
kfree(foo->bar);
err_free_foo:
kfree(foo);
return ret;
Ideally you should simulate errors to test all exit paths.
Chapter 8: Commenting Chapter 8: Commenting