[libvirt] [PATCH 0/1] Documenting the uses of goto
I added a section on good and bad uses of goto to the hacking document and website. Also, should we dispense with the HACKING file's content altogether and replace it with a link to hacking.html on the website? It seems like unnecessary work to maintain identical content in both places. Dave David Allan (1): The use of goto HACKING | 32 ++++++++++++++++++++++++++++++++ docs/hacking.html.in | 41 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 73 insertions(+), 0 deletions(-)
* Added a section on the appropriate and inappropriate uses of goto to the HACKING document and website. --- HACKING | 32 ++++++++++++++++++++++++++++++++ docs/hacking.html.in | 41 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 73 insertions(+), 0 deletions(-) diff --git a/HACKING b/HACKING index be8725d..db99630 100644 --- a/HACKING +++ b/HACKING @@ -362,6 +362,38 @@ their jobs and cross-check format strings with the number and types of arguments. +Use of goto +=========== + +The use of goto is not forbidden, and goto is widely used throughout +libvirt. While the uncontrolled use of goto will quickly lead to +unmaintainable code, there is a place for it in well structured code +where its use increases readability and maintainability. + +The typical use of goto is to jump to cleanup code in the case of a +long list of actions, any of which may fail and cause the entire +operation to fail. In this case, a function will have a single label +at the end of the funcion. It's almost always ok to use this style. +In particular, if the cleanup code only involves free'ing memory, then +having multiple labels is overkill. VIR_FREE() and every function +named XXXFree() in libvirt is required to handle NULL as its arg. +Thus you can safely call free on all the variables even if they were +not yet allocated (yes they have to have been initialized to NULL). +This is much simpler and clearer than having multiple labels. + +There are a couple of signs that a particular use of goto is not ok. +The first is the use of multiple labels. If you find yourself using +multiple labels, you're strongly encouraged to rework your code to +eliminate all but one of them. The second is jumping back up, above +the current line of code being executed. Please use some combination +of looping constructs to re-execute code instead; it's almost +certainly going to be more understandable by others. + +Although libvirt does not encourage the Linux kernel wind/unwind style +of multiple labels, there's a good general discussion of the issue at: + +http://kerneltrap.org/node/553/2131 + Libvirt commiters guidelines ============================ diff --git a/docs/hacking.html.in b/docs/hacking.html.in index 788a49b..e10d2dd 100644 --- a/docs/hacking.html.in +++ b/docs/hacking.html.in @@ -389,6 +389,47 @@ of arguments. </p> + <h2><a name="goto">Use of goto</a></h2> + + <p> + The use of goto is not forbidden, and goto is widely used + throughout libvirt. While the uncontrolled use of goto will + quickly lead to unmaintainable code, there is a place for it in + well structured code where its use increases readability and + maintainability. + </p> + + <p> + The typical use of goto is to jump to cleanup code in the case + of a long list of actions, any of which may fail and cause the + entire operation to fail. In this case, a function will have a + single label at the end of the funcion. It's almost always ok + to use this style. In particular, if the cleanup code only + involves free'ing memory, then having multiple labels is + overkill. VIR_FREE() and every function named XXXFree() in + libvirt is required to handle NULL as its arg. Thus you can + safely call free on all the variables even if they were not yet + allocated (yes they have to have been initialized to NULL). + This is much simpler and clearer than having multiple labels. + </p> + + <p> + There are a couple of signs that a particular use of goto is not + ok. The first is the use of multiple labels. If you find + yourself using multiple labels, you're strongly encouraged to + rework your code to eliminate all but one of them. The second + is jumping back up, above the current line of code being + executed. Please use some combination of looping constructs to + re-execute code instead; it's almost certainly going to be more + understandable by others. + </p> + + <p> + Although libvirt does not encourage the Linux kernel wind/unwind + style of multiple labels, there's a good general discussion of + the issue archived at + <a href=http://kerneltrap.org/node/553/2131>KernelTrap</a> + </p> <h2><a name="committers">Libvirt commiters guidelines</a></h2> -- 1.6.5.5
According to David Allan on 3/5/2010 10:25 AM:
* Added a section on the appropriate and inappropriate uses of goto to the HACKING document and website. --- HACKING | 32 ++++++++++++++++++++++++++++++++ docs/hacking.html.in | 41 +++++++++++++++++++++++++++++++++++++++++
ACK. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Fri, Mar 05, 2010 at 12:25:19PM -0500, David Allan wrote:
* Added a section on the appropriate and inappropriate uses of goto to the HACKING document and website. --- HACKING | 32 ++++++++++++++++++++++++++++++++ docs/hacking.html.in | 41 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/HACKING b/HACKING index be8725d..db99630 100644 --- a/HACKING +++ b/HACKING @@ -362,6 +362,38 @@ their jobs and cross-check format strings with the number and types of arguments.
+Use of goto +=========== + +The use of goto is not forbidden, and goto is widely used throughout +libvirt. While the uncontrolled use of goto will quickly lead to +unmaintainable code, there is a place for it in well structured code +where its use increases readability and maintainability. + +The typical use of goto is to jump to cleanup code in the case of a +long list of actions, any of which may fail and cause the entire +operation to fail. In this case, a function will have a single label +at the end of the funcion. It's almost always ok to use this style. +In particular, if the cleanup code only involves free'ing memory, then +having multiple labels is overkill. VIR_FREE() and every function +named XXXFree() in libvirt is required to handle NULL as its arg. +Thus you can safely call free on all the variables even if they were +not yet allocated (yes they have to have been initialized to NULL). +This is much simpler and clearer than having multiple labels. + +There are a couple of signs that a particular use of goto is not ok. +The first is the use of multiple labels. If you find yourself using +multiple labels, you're strongly encouraged to rework your code to +eliminate all but one of them. The second is jumping back up, above +the current line of code being executed. Please use some combination +of looping constructs to re-execute code instead; it's almost +certainly going to be more understandable by others.
+Although libvirt does not encourage the Linux kernel wind/unwind style +of multiple labels, there's a good general discussion of the issue at: + +http://kerneltrap.org/node/553/2131 +
Thanks, it would be good if we documented a consistent naming scheme for labels too. error: A path only taken upon return with an error code cleanup: A path taken upon return with success code + optional error no_memory: A path only taken upon return with an OOM error code retry: If needing to jump upwards (eg retry on EINTR) There are plenty of violations of these 4 names, but they are the most common, so we might want to convert others to use these names, or avoid goto if it wasn't appropriate. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
David Allan wrote:
* Added a section on the appropriate and inappropriate uses of goto to the HACKING document and website. ---
Good to write that down.
+Use of goto +=========== + +The use of goto is not forbidden, and goto is widely used throughout +libvirt. While the uncontrolled use of goto will quickly lead to +unmaintainable code, there is a place for it in well structured code +where its use increases readability and maintainability. + +The typical use of goto is to jump to cleanup code in the case of a +long list of actions, any of which may fail and cause the entire +operation to fail. In this case, a function will have a single label +at the end of the funcion. It's almost always ok to use this style.
s/funcion/function/ ...
Libvirt commiters guidelines ============================ diff --git a/docs/hacking.html.in b/docs/hacking.html.in
...
+ The typical use of goto is to jump to cleanup code in the case + of a long list of actions, any of which may fail and cause the + entire operation to fail. In this case, a function will have a + single label at the end of the funcion. It's almost always ok
Likewise ^^^^^^
+ to use this style. In particular, if the cleanup code only + involves free'ing memory, then having multiple labels is ...
According to David Allan on 3/5/2010 10:25 AM:
I added a section on good and bad uses of goto to the hacking document and website.
Also, should we dispense with the HACKING file's content altogether and replace it with a link to hacking.html on the website?
It seems like unnecessary work to maintain identical content in both
Is there a make rule to generate one from the other? places. Agreed, and my recent ACK'd patch that documented preprocessor guidelines failed to update the web version. I guess I'd better respin it, until such time as we only have one master document. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Fri, Mar 05, 2010 at 10:41:09AM -0700, Eric Blake wrote:
According to David Allan on 3/5/2010 10:25 AM:
I added a section on good and bad uses of goto to the hacking document and website.
Also, should we dispense with the HACKING file's content altogether and replace it with a link to hacking.html on the website?
Is there a make rule to generate one from the other?
I think the HTML version is more important. Either we can kill HACKING or do a HTML->Text conversion for it Daneiel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Fri, Mar 05, 2010 at 05:56:01PM +0000, Daniel P. Berrange wrote:
On Fri, Mar 05, 2010 at 10:41:09AM -0700, Eric Blake wrote:
According to David Allan on 3/5/2010 10:25 AM:
I added a section on good and bad uses of goto to the hacking document and website.
Also, should we dispense with the HACKING file's content altogether and replace it with a link to hacking.html on the website?
Is there a make rule to generate one from the other?
I think the HTML version is more important. Either we can kill HACKING or do a HTML->Text conversion for it
I think keeping a text version for that one is at least in spirit a good idea, just generate it from HTML. I suggest to commit the change to the hacking.html.in but not change the text file yet, I will try to come up with the tiny XSLT needed to generate it hopefully this week. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On 03/08/2010 10:21 AM, Daniel Veillard wrote:
On Fri, Mar 05, 2010 at 05:56:01PM +0000, Daniel P. Berrange wrote:
On Fri, Mar 05, 2010 at 10:41:09AM -0700, Eric Blake wrote:
According to David Allan on 3/5/2010 10:25 AM:
I added a section on good and bad uses of goto to the hacking document and website.
Also, should we dispense with the HACKING file's content altogether and replace it with a link to hacking.html on the website?
Is there a make rule to generate one from the other?
I think the HTML version is more important. Either we can kill HACKING or do a HTML->Text conversion for it
I think keeping a text version for that one is at least in spirit a good idea, just generate it from HTML.
I suggest to commit the change to the hacking.html.in but not change the text file yet, I will try to come up with the tiny XSLT needed to generate it hopefully this week.
Ok, thanks Daniel. I've pushed just the hacking.html.in Dave
* docs/hacking.html.in (committers): Fix spelling and grammar. --- Per the very text I'm editing, this counts as trivial :) docs/hacking.html.in | 26 +++++++++++++++----------- 1 files changed, 15 insertions(+), 11 deletions(-) diff --git a/docs/hacking.html.in b/docs/hacking.html.in index 2016b28..15029ac 100644 --- a/docs/hacking.html.in +++ b/docs/hacking.html.in @@ -514,38 +514,42 @@ - <h2><a name="committers">Libvirt commiters guidelines</a></h2> + <h2><a name="committers">Libvirt committers guidelines</a></h2> <p> - The AUTHORS files indicates the list of people with commit acces right + The AUTHORS files indicates the list of people with commit access right who can actually merge the patches. </p> <p> - The general rule for commiting patches is to make sure it has been reviewed + The general rule for committing patches is to make sure it has been reviewed properly in the mailing-list first, usually if a couple of persons gave an ACK or +1 to a patch and nobody raised an objection on the list it should be good to go. If the patch touches a part of the code where you're not the - main maintainer or not have a very clear idea of how things work, it's better - to wait for a more authoritative feedback though. Before commiting please - also rebuild locally and run 'make check syntax-check' and make sure they - don't raise error. Try to look for warnings too for example configure with + main maintainer, or where you donot have a very clear idea of + how things work, it's better + to wait for a more authoritative feedback though. Before committing, please + also rebuild locally, run 'make check syntax-check', and make sure you + don't raise errors. Try to look for warnings too; for example, + configure with +<pre> --enable-compile-warnings=error +</pre> which adds -Werror to compile flags, so no warnings get missed </p> <p> - Exceptions to that 'review and approval on the list first' is fixing failures + An exception to 'review and approval on the list first' is fixing failures to build: </p> <ul> - <li>if a recently commited patch breaks compilation on a platform - or for a given driver then it's fine to commit a minimal fix + <li>if a recently committed patch breaks compilation on a platform + or for a given driver, then it's fine to commit a minimal fix directly without getting the review feedback first</li> <li>if make check or make syntax-check breaks, if there is an obvious fix, it's fine to commit immediately. The patch should still be sent to the list (or tell what the fix was if - trivial) and 'make check syntax-check' should pass too before commiting + trivial), and 'make check syntax-check' should pass too, before committing anything</li> <li> fixes for documentation and code comments can be managed -- 1.6.6.1
Eric Blake wrote:
* docs/hacking.html.in (committers): Fix spelling and grammar. ---
Per the very text I'm editing, this counts as trivial :)
docs/hacking.html.in | 26 +++++++++++++++----------- 1 files changed, 15 insertions(+), 11 deletions(-) ...
Applied, with these additional changes: diff --git a/HACKING b/HACKING index be8725d..b6f63dd 100644 --- a/HACKING +++ b/HACKING @@ -369,8 +369,8 @@ of arguments. The AUTHORS files indicates the list of people with commit acces right who can actually merge the patches. -The general rule for commiting patches is to make sure it has been reviewed -properly in the mailing-list first, usually if a couple of persons gave an +The general rule for commiting a patch is to make sure it has been reviewed +properly in the mailing-list first, usually if a couple of people gave an ACK or +1 to a patch and nobody raised an objection on the list it should be good to go. If the patch touches a part of the code where you're not the main maintainer or not have a very clear idea of how things work, it's better
On 03/09/2010 09:03 AM, Jim Meyering wrote:
The AUTHORS files indicates the list of people with commit acces right who can actually merge the patches.
-The general rule for commiting patches is to make sure it has been reviewed -properly in the mailing-list first, usually if a couple of persons gave an +The general rule for commiting a patch is to make sure it has been reviewed +properly in the mailing-list first, usually if a couple of people gave an
Sorry for not spotting it sooner, but s/commiting/committing/ (2 t's) -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Eric Blake wrote:
On 03/09/2010 09:03 AM, Jim Meyering wrote:
The AUTHORS files indicates the list of people with commit acces right who can actually merge the patches.
-The general rule for commiting patches is to make sure it has been reviewed -properly in the mailing-list first, usually if a couple of persons gave an +The general rule for commiting a patch is to make sure it has been reviewed +properly in the mailing-list first, usually if a couple of people gave an
Sorry for not spotting it sooner, but s/commiting/committing/ (2 t's)
No problem. I made a quick pass through it and fixed a bunch more:
From 7f2ae0da9097a4aea87f25adab0f50881a8b7ccf Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering@redhat.com> Date: Tue, 9 Mar 2010 17:21:55 +0100 Subject: [PATCH] doc: fix more typos in HACKING
* HACKING: More spelling/typo fixes. --- HACKING | 20 ++++++++++---------- 1 files changed, 10 insertions(+), 10 deletions(-) diff --git a/HACKING b/HACKING index 9ee87c1..b94487c 100644 --- a/HACKING +++ b/HACKING @@ -96,7 +96,7 @@ around operators and keywords: --no-tabs "$@" } -Note that sometimes you'll have to postprocess that output further, by +Note that sometimes you'll have to post-process that output further, by piping it through "expand -i", since some leading TABs can get through. Usually they're in macro definitions or strings, and should be converted anyhow. @@ -342,7 +342,7 @@ complexity it's best to stick to the following general plan for all #include <limits.h> #if HAVE_NUMACTL Some system includes aren't supported - #include <numa.h> everywhere so need these #if defences. + # include <numa.h> everywhere so need these #if guards. #endif #include "internal.h" Include this first, after system includes. @@ -377,18 +377,18 @@ of arguments. - Libvirt commiters guidelines + Libvirt committer guidelines ============================ -The AUTHORS files indicates the list of people with commit acces right +The AUTHORS files indicates the list of people with commit access right who can actually merge the patches. -The general rule for commiting a patch is to make sure it has been reviewed +The general rule for committing a patch is to make sure it has been reviewed properly in the mailing-list first, usually if a couple of people gave an ACK or +1 to a patch and nobody raised an objection on the list it should be good to go. If the patch touches a part of the code where you're not the main maintainer or not have a very clear idea of how things work, it's better -to wait for a more authoritative feedback though. Before commiting please +to wait for a more authoritative feedback though. Before committing please also rebuild locally and run 'make check syntax-check' and make sure they don't raise error. Try to look for warnings too for example configure with --enable-compile-warnings=error @@ -396,13 +396,13 @@ which adds -Werror to compile flags, so no warnings get missed Exceptions to that 'review and approval on the list first' is fixing failures to build: - - if a recently commited patch breaks compilation on a platform + - if a recently committed patch breaks compilation on a platform or for a given driver then it's fine to commit a minimal fix directly without getting the review feedback first - - similary if make check or make syntax-check breaks, if there is + - similarly, if make check or make syntax-check breaks, if there is an obvious fix, it's fine to commit immediately The patch should still be sent to the list (or tell what the fix was if -trivial) and 'make check syntax-check' should pass too before commiting +trivial) and 'make check syntax-check' should pass too before committing anything -Similary fixes for documentation and code comments can be managed +Similar fixes for documentation and code comments can be managed in the same way, but still make sure they get reviewed if non-trivial. -- 1.7.0.2.329.gdaec6
On 03/09/2010 09:22 AM, Jim Meyering wrote:
Eric Blake wrote:
On 03/09/2010 09:03 AM, Jim Meyering wrote:
The AUTHORS files indicates the list of people with commit acces right who can actually merge the patches.
-The general rule for commiting patches is to make sure it has been reviewed -properly in the mailing-list first, usually if a couple of persons gave an +The general rule for commiting a patch is to make sure it has been reviewed +properly in the mailing-list first, usually if a couple of people gave an
Sorry for not spotting it sooner, but s/commiting/committing/ (2 t's)
No problem. I made a quick pass through it and fixed a bunch more:
Actually, the whole point is that HACKING and docs/hacking.html.in are more or less duplicates of one another, and someone volunteered to make HACKING be autogenerated from the html version. Therefore, patching HACKING is not worth much (otherwise I would have patched both files in the first place); but your grammar change to go from 'committing patches' to 'committing a patch' should be flowed back to the html version. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Eric Blake wrote:
On 03/09/2010 09:22 AM, Jim Meyering wrote:
Eric Blake wrote:
On 03/09/2010 09:03 AM, Jim Meyering wrote:
The AUTHORS files indicates the list of people with commit acces right who can actually merge the patches.
-The general rule for commiting patches is to make sure it has been reviewed -properly in the mailing-list first, usually if a couple of persons gave an +The general rule for commiting a patch is to make sure it has been reviewed +properly in the mailing-list first, usually if a couple of people gave an
Sorry for not spotting it sooner, but s/commiting/committing/ (2 t's)
No problem. I made a quick pass through it and fixed a bunch more:
Actually, the whole point is that HACKING and docs/hacking.html.in are more or less duplicates of one another, and someone volunteered to make HACKING be autogenerated from the html version. Therefore, patching HACKING is not worth much (otherwise I would have patched both files in the first place); but your grammar change to go from 'committing patches' to 'committing a patch' should be flowed back to the html version.
Good point. This should help me avoid making that mistake again.
From 1b2adcb9f09266099e6df9b2d53bacb39bf7421c Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering@redhat.com> Date: Tue, 9 Mar 2010 17:59:25 +0100 Subject: [PATCH] doc: fix typos in hacking.html.in; mark HACKING as read-only
* HACKING: Mark as read-only. Soon we'll generate it from... * docs/hacking.html.in: ... this file. More typo fixes. --- HACKING | 3 +++ docs/hacking.html.in | 15 ++++++++------- 2 files changed, 11 insertions(+), 7 deletions(-) diff --git a/HACKING b/HACKING index b94487c..5486d8e 100644 --- a/HACKING +++ b/HACKING @@ -1,3 +1,6 @@ +-*- buffer-read-only: t -*- vi: set ro: +DO NOT EDIT THIS FILE! IT IS GENERATED AUTOMATICALLY! + Libvirt contributor guidelines ============================== diff --git a/docs/hacking.html.in b/docs/hacking.html.in index 8771c54..f5ec635 100644 --- a/docs/hacking.html.in +++ b/docs/hacking.html.in @@ -117,7 +117,7 @@ </pre> <p> - Note that sometimes you'll have to postprocess that output further, by + Note that sometimes you'll have to post-process that output further, by piping it through "expand -i", since some leading TABs can get through. Usually they're in macro definitions or strings, and should be converted anyhow. @@ -424,7 +424,7 @@ #include <limits.h> #if HAVE_NUMACTL Some system includes aren't supported - # include <numa.h> everywhere so need these #if defences. + # include <numa.h> everywhere so need these #if guards. #endif #include "internal.h" Include this first, after system includes. @@ -533,7 +533,7 @@ - <h2><a name="committers">Libvirt committers guidelines</a></h2> + <h2><a name="committers">Libvirt committer guidelines</a></h2> <p> The AUTHORS files indicates the list of people with commit access right @@ -541,11 +541,12 @@ </p> <p> - The general rule for committing patches is to make sure it has been reviewed - properly in the mailing-list first, usually if a couple of persons gave an + The general rule for committing a patch is to make sure + it has been reviewed + properly in the mailing-list first, usually if a couple of people gave an ACK or +1 to a patch and nobody raised an objection on the list it should - be good to go. If the patch touches a part of the code where you're not the - main maintainer, or where you donot have a very clear idea of + be good to go. If the patch touches a part of the code where you're not + the main maintainer, or where you do not have a very clear idea of how things work, it's better to wait for a more authoritative feedback though. Before committing, please also rebuild locally, run 'make check syntax-check', and make sure you -- 1.7.0.2.329.gdaec6
* doc/hacking.html.in (preprocessor): New section to document recently-discussed style issues. Signed-off-by: Eric Blake <eblake@redhat.com> --- This patch assumes that we are willing to mass-update preprocessor indentation via Jim's cppi tool. HACKING | 14 ++++++++++++++ docs/hacking.html.in | 21 ++++++++++++++++++++- 2 files changed, 34 insertions(+), 1 deletions(-) diff --git a/HACKING b/HACKING index be8725d..4bc7b52 100644 --- a/HACKING +++ b/HACKING @@ -102,6 +102,20 @@ Usually they're in macro definitions or strings, and should be converted anyhow. +Preprocessor +============ +For variadic macros, stick with C99 syntax: + +#define vshPrint(_ctl, ...) fprintf(stdout, __VA_ARGS__) + +Use parenthesis when checking if a macro is defined, and use +indentation to track nesting: + +#if defined(HAVE_POSIX_FALLOCATE) && !defined(HAVE_FALLOCATE) +# define fallocate(a,ignored,b,c) posix_fallocate(a,b,c) +#endif + + C types ======= Use the right type. diff --git a/docs/hacking.html.in b/docs/hacking.html.in index 15029ac..8771c54 100644 --- a/docs/hacking.html.in +++ b/docs/hacking.html.in @@ -124,6 +124,25 @@ </p> + <h2><a href="types">Preprocessor</a></h2> + + <p> + For variadic macros, stick with C99 syntax: + <pre> + #define vshPrint(_ctl, ...) fprintf(stdout, __VA_ARGS__) + </pre> + </p> + + <p>Use parenthesis when checking if a macro is defined, and use + indentation to track nesting: + + <pre> + #if defined(HAVE_POSIX_FALLOCATE) && !defined(HAVE_FALLOCATE) + # define fallocate(a,ignored,b,c) posix_fallocate(a,b,c) + #endif + </pre> + </p> + <h2><a href="types">C types</a></h2> <p> @@ -405,7 +424,7 @@ #include <limits.h> #if HAVE_NUMACTL Some system includes aren't supported - #include <numa.h> everywhere so need these #if defences. + # include <numa.h> everywhere so need these #if defences. #endif #include "internal.h" Include this first, after system includes. -- 1.6.6.1
Eric Blake wrote:
* doc/hacking.html.in (preprocessor): New section to document recently-discussed style issues.
This patch assumes that we are willing to mass-update preprocessor indentation via Jim's cppi tool.
Thanks for writing that. Obviously I would not object. Daniel Veillard ok'd it, too, so I've pushed it.
participants (6)
-
Daniel P. Berrange -
Daniel Veillard -
Dave Allan -
David Allan
-
Eric Blake -
Jim Meyering