Re: RFC: style(9) isn't explicit about booleans for testing -- an actual analysis of the code!
On Thursday 07 March 2002 12:59 am, Poul-Henning Kamp wrote:
| In message [EMAIL PROTECTED], David O'Brien writes:
| Implies??? I thought I was quite explicit:
|
| to prevent is if (!strcmp(a,b)) which when read is extremely wrong
| of that is actually happening.
|
| ! is pronounced NOT. When read if not string compare a with b then do
| X, is the opposite of the the logic of the expression does. Which is
| if string compare a with b is equal then do X. [if (strcmp(a,b) ==
| 0)]
|
| Well, we're clearly into IMO land here, so lets ignore that :-)
No, we aren't, and let's not.
Maybe your brain has gotten used to it, but to us ordinary mortals, even us
ordinary mortals who've been slogging C code for time periods that can be
measured in decades (yikes!), it is very tempting to read
i f (!strcmp(a,b,l))
as if the strings don't compare which , in ordinary usage, means don't
compare *equal*. But of course the C program is going to proceed to do
exactly the opposite of that.
Now, I personally find the constructions
if (!p) do_thing_for_null_pointer;
and
if (p) do_thing_for_valid_pointer;
quite readable and would prefer that an abstract Guide To Perfect Style
blessed them since I find them quite readable as if I don't have a pointer
and if I do have a pointer.
But *ALL* of this is beside the nominal point ANYWAY, which is to discuss
the proper wording for the man(9) style guide which is supposed to document
how things things are actually done in the kernel, not personal preference.
===
So I just grepped the code
(find /usr/src -type f -exec grep 'if.*strcmp' {} \;)
and analyize the results.
Overall, there are 1831 !strcmp test and 3363 strcmp.*==0 tests
Within the kernel there are 84 !strcmp tests and 155 strcmp.*== 0 tests
So 65% either way in favor of the proposed change in wording -- a 2:1
majority of the code votes FOR the proposed change.
(This is subject to minor error given that it's all based on greps and
statistics, but I did the analysis a few different ways using different
plausible regular expressions to determine the two code paths, and all of
analysis showed that it was at least 2:1 using the == / != 0 tests.)
--
Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work)
Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal)
ME -- http://www.babbleon.org
http://www.eff.org -- GOOD GUYS -- http://www.programming-freedom.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing -- anactual analysis of the code!
At 2:16 AM -0500 3/7/02, Brian T.Schellenberger wrote: Maybe your brain has gotten used to it, but to us ordinary mortals, even us ordinary mortals who've been slogging C code for time periods that can be measured in decades (yikes!), it is very tempting to read if (!strcmp(a,b,l)) as if the strings don't compare which, in ordinary usage, means don't compare *equal*. But of course the C program is going to proceed to do exactly the opposite of that. Okay, I will agree I have made that mistake a few times. Not often, but it really burns me up when I realize that's the source of some bug. So, that sounds like a good reason. But *ALL* of this is beside the nominal point ANYWAY, which is to discuss the proper wording for the man(9) style guide which is supposed to document how things things are actually done in the kernel, not personal preference. As to the wording, PHK suggested that the wording for this rule in style(9) be changed: - - - get rid of the word boolean, ie: change Do not use ! for tests unless it is a boolean, e.g. use to Do not use ! for tests unless it is an integer type, e.g. use - - - Dave O'Brien claimed the very same rule was *only* there to prevent if (!strcmp(a,b)). May I suggest that we probably want two different rules? Change the current rule so it says 'integer type' instead of 'boolean' (which doesn't really exist in C anyway), and then add the rule about strcmp()? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing -- an actual analysis of the code!
In a message written on Thu, Mar 07, 2002 at 03:27:49PM -0500, Garance A Drosihn wrote:
As to the wording, PHK suggested that the wording for this
rule in style(9) be changed:
- - -
get rid of the word boolean, ie: change
Do not use ! for tests unless it is a boolean, e.g. use
to
Do not use ! for tests unless it is an integer type, e.g. use
Although C doesn't have the type boolean, I believe this is a
conceptual distinction. That is, we don't want to allow this:
if (!uid) {
/* do thing only root can do */
}
Because UID is not a boolean type. It takes a range of values,
and should be:
if (uid == 0) {
/* do thing only root can do */
}
The only proper use of ! is on a boolean type, defined as a type
that has two values, 0, and everything else.
Personally, I would clarify boolean in the document as follows:
C does not provide a proper boolean type. As a result, FreeBSD
uses integers for a boolean type. The boolean values are 0 for
false, and all other values for true. All code using a boolean
type must not depend on true having any specific value.
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
On Wed, Mar 06, 2002 at 01:19:31AM -0600, Mike Meyer wrote: David O'Brien [EMAIL PROTECTED] types: On Wed, Mar 06, 2002 at 02:08:07AM +0200, Giorgos Jeremiahs wrote: I was giving one. :-) style(9) documents the practices of /sys. Thus we should not arbitaryly add rules w/o them being backed up in code. As the original author of the PR, I'll point out that this chagne does *not* add rules. It clarifies the wording of a rule that's already there. If the rule is wrong, it should be removed. The reason I didn't post if for wider review was because it wasn't changing any rules. My thanks to Giorgos for moving this PR towards closure. I don't think it is clarifying a rule. I think it is in fact adding a rule. You are extrapolating too much I think. All the rule is trying to prevent is if (!strcmp(a,b)) which when read is extremely wrong of that is actually happening. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
On Tue, Mar 05, 2002 at 11:35:52PM -0700, M. Warner Losh wrote:
: I was giving one. :-)
: style(9) documents the practices of /sys. Thus we should not arbitaryly
: add rules w/o them being backed up in code.
I believe that sys/pccard, sys/dev/{pccard,pcic,pccbb,cardbus} tends
to follow this rule. If you are looking for examples.
Older code than PCCARD. :-)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
In message [EMAIL PROTECTED], Mike Meyer writes: Poul-Henning Kamp [EMAIL PROTECTED] types: In message [EMAIL PROTECTED], Mike Meyer writes: I'm advocating that the rule focus on readability rather than trying to enforce a type which doesn't exist. Excellent idea. Can you provide verbiage and examples? All you have to do is get rid of the word boolean, ie: change Do not use ! for tests unless it is a boolean, e.g. use to Do not use ! for tests unless it is an integer type, e.g. use And as far as I'm concerned the confusion is gone. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
David O'Brien [EMAIL PROTECTED] types:
On Wed, Mar 06, 2002 at 01:19:31AM -0600, Mike Meyer wrote:
David O'Brien [EMAIL PROTECTED] types:
As the original author of the PR, I'll point out that this chagne does
*not* add rules. It clarifies the wording of a rule that's already
there. If the rule is wrong, it should be removed. The reason I didn't
post if for wider review was because it wasn't changing any rules. My
thanks to Giorgos for moving this PR towards closure.
I don't think it is clarifying a rule. I think it is in fact adding a
rule. You are extrapolating too much I think. All the rule is trying
to prevent is if (!strcmp(a,b)) which when read is extremely wrong of
that is actually happening.
Ok, I was attempting to clarify a rule, but misinterpreted. Which just
reinforces the need for clarifing it.
Being an old lisp hand, I'm used to functions that return a value or
nil to indicate an error of some kind, and programs that just check
the value are SOP.
I'll grant that the change Paul suggested makes it clear - the
programmer knows when the function is returning an int or not. But
it's not clear that it achieves his intent. is
char *p;
if (p = somerandomfunction(with, args)) {
}
really less readable than:
char *p;
if ((p = somerandomfunction(with, args)) != NULL) {
}
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
In message [EMAIL PROTECTED], Mike Meyer writes:
I'll grant that the change Paul suggested makes it clear - the
programmer knows when the function is returning an int or not. But
it's not clear that it achieves his intent. is
char *p;
if (p = somerandomfunction(with, args)) {
}
really less readable than:
char *p;
if ((p = somerandomfunction(with, args)) != NULL) {
}
Ahh, but here you hit one of my pet-peeves. I hate assignments inside
conditionals. I prefer the above written as:
char *p;
p = somerandomfunction(with, args);
if (p != NULL) {
}
Anyway, if you want it spelled out the way I would want it:
0. No assignments in if()
1. In conditions, pointers should be explicitly compared against NULL:
if (foo == NULL)
or
if (foo != NULL)
2. In conditions, non-interger numeric types should be explicitly compared
to zero
if (float_t == 0.0)
3. Integers need not be explicitly compared to zero:
if (foo MASK)
not
if ((foo MASK) != 0)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
Poul-Henning Kamp [EMAIL PROTECTED] types: Ahh, but here you hit one of my pet-peeves. I hate assignments inside conditionals. I prefer the above written as: Anyway, if you want it spelled out the way I would want it: 0. No assignments in if() 1. In conditions, pointers should be explicitly compared against NULL: if (foo == NULL) or if (foo != NULL) 2. In conditions, non-interger numeric types should be explicitly compared to zero if (float_t == 0.0) 3. Integers need not be explicitly compared to zero: if (foo MASK) not if ((foo MASK) != 0) I would like it spelled out. Since style(9) uses assignments in conditionals in it's examples, rule 0 probably won't fly. Rule 1 and 2 are redundant. Looking at the text in the page on -stable, I think the one-word change from boolean to integer would remove the ambiguity. Thank you, mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
In message [EMAIL PROTECTED], David O'Brien cleopede: I don't think it is clarifying a rule. I think it is in fact adding a rule. You are extrapolating too much I think. All the rule is trying to prevent is if (!strcmp(a,b)) which when read is extremely wrong of that is actually happening. Too bad strcmp wasn't named strdiff--just think of all the hassle that would have prevented over the years... Greg Shenaut To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
On Wed, Mar 06, 2002 at 11:37:42AM +0100, Poul-Henning Kamp wrote: Ahh, but here you hit one of my pet-peeves. I hate assignments inside conditionals. I prefer the above written as: It does not matter. Style(9) does not [intentionally] avoid PHK's pet peeves. It documents the style used by the CSRG with some modernizations. All this IMO does not matter as much as showing actual code examples from /sys. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
In one message, At 12:52 AM -0800 3/6/02, David O'Brien wrote: I don't think it is clarifying a rule. I think it is in fact adding a rule. You are extrapolating too much I think. All the rule is trying to prevent is if (!strcmp(a,b)) which when read is extremely wrong of that is actually happening. In a later message (not directly replying to the above), At 4:44 AM -0600 3/6/02, Mike Meyer wrote: Looking at the text in the page on -stable, I think the one-word change from boolean to integer would remove the ambiguity. If we change boolean to integer, then the proposed rule will not prevent if (!strcmp(a,b)) , because strcmp() *does* return an integer value. Or am I missing something here? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
In message p0510150fb8ac11d15f26@[128.113.24.47], Garance A Drosihn writes: In one message, At 12:52 AM -0800 3/6/02, David O'Brien wrote: I don't think it is clarifying a rule. I think it is in fact adding a rule. You are extrapolating too much I think. All the rule is trying to prevent is if (!strcmp(a,b)) which when read is extremely wrong of that is actually happening. In a later message (not directly replying to the above), At 4:44 AM -0600 3/6/02, Mike Meyer wrote: Looking at the text in the page on -stable, I think the one-word change from boolean to integer would remove the ambiguity. If we change boolean to integer, then the proposed rule will not prevent if (!strcmp(a,b)) , because strcmp() *does* return an integer value. Or am I missing something here? Right, and since the integer is well defined, if (!strcmp(a, b)) is perfectly understandable so what is the problem ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
At 7:49 PM +0100 3/6/02, Poul-Henning Kamp wrote: Garance A Drosihn writes: In one message, At 12:52 AM -0800 3/6/02, David O'Brien wrote: I don't think it is clarifying a rule. I think it is in fact adding a rule. You are extrapolating too much I think. All the rule is trying to prevent is if (!strcmp(a,b)) which when read is extremely wrong of that is actually happening. If we change boolean to integer, then the proposed rule will not prevent if (!strcmp(a,b)) , because strcmp() *does* return an integer value. Or am I missing something here? Right, and since the integer is well defined, if (!strcmp(a, b)) is perfectly understandable so what is the problem ? Well, that's my question. David's comment implies that it is not good to do '!strcmp()', and I was wondering why it is not good... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
On Wed, Mar 06, 2002 at 02:37:45PM -0500, Garance A Drosihn wrote: At 7:49 PM +0100 3/6/02, Poul-Henning Kamp wrote: Garance A Drosihn writes: In one message, At 12:52 AM -0800 3/6/02, David O'Brien wrote: I don't think it is clarifying a rule. I think it is in fact adding a rule. You are extrapolating too much I think. All the rule is trying to prevent is if (!strcmp(a,b)) which when read is extremely wrong of that is actually happening. If we change boolean to integer, then the proposed rule will not prevent if (!strcmp(a,b)) , because strcmp() *does* return an integer value. Or am I missing something here? Right, and since the integer is well defined, if (!strcmp(a, b)) is perfectly understandable so what is the problem ? Well, that's my question. David's comment implies that it is not good to do '!strcmp()', and I was wondering why it is not good... Implies??? I thought I was quite explicit: to prevent is if (!strcmp(a,b)) which when read is extremely wrong of that is actually happening. ! is pronounced NOT. When read if not string compare a with b then do X, is the opposite of the the logic of the expression does. Which is if string compare a with b is equal then do X. [if (strcmp(a,b) == 0)] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
Poul-Henning Kamp [EMAIL PROTECTED] wrote: I had a discussion with Eric Allman about this very thing recently where he advocated everything inside if, while, for and so on should be true booleans. Now, IFF the C language had a type called boolean that would make a lot of sense. Unfortunately, it does not (at present ?) have a boolean type, and while one could simulate it with typedefs, there is no way to get the compiler to enforce the rule. C99 has a boolean type, but neither the comparison operators nor the logical operators nor the ! operator return a bool, and conditional contexts (like if, while, ?:) don't expect a bool. Pretty useless, really. Tony. -- f.a.n.finch [EMAIL PROTECTED] ROCKALL: WEST BACKING SOUTHWEST 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9 AT FIRST, DECREASING 5 FOR A TIME. OCCASIONAL RAIN. MODERATE. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
Poul-Henning Kamp [EMAIL PROTECTED] wrote: Right, and since the integer is well defined, if (!strcmp(a, b)) is perfectly understandable so what is the problem ? If that is ok, then why is p = malloc(sizeof(*p)); if (!p) return ENOMEM; not ok, given that is even more well-defined? I am of the opinion that expressions in a conditional context (i.e. argument of ! || ?: if while) should be boolean-valued (i.e. either 0 or 1 corresponding to false or true). If they aren't then an appropriate comparison should be done. Tony. -- f.a.n.finch [EMAIL PROTECTED] FAEROES SOUTHEAST ICELAND: EASTERLY, BECOMING CYCLONIC THEN WESTERLY, 4 OR 5. SNOW OR SNOW SHOWERS. GOOD OCCASIONALLY POOR. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
Try this text instead: In C, there is no boolean type but there are boolean concepts, contexts that express or test yes/no, good/bad, error/success, pointer initialized/not initialized, object created/not created, and so on. Where a conceptually boolean operand is expected and you have a value that is not conceptually boolean, use an operator (e.g., ==, !=) that translates the operand to something that is conceptually boolean. This applies to if expressions, the operand of !, function parameters that want a conceptually boolean value, and so on. This is actually a special case of a more general rule, which might be stated: saving a few keystrokes but violating the expectations of strangers reading your code is not a good way to write maintainable code. Ensure that the code and your intention are congruent *in the mind of your readers*. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
In message [EMAIL PROTECTED], David O'Brien writes: Implies??? I thought I was quite explicit: to prevent is if (!strcmp(a,b)) which when read is extremely wrong of that is actually happening. ! is pronounced NOT. When read if not string compare a with b then do X, is the opposite of the the logic of the expression does. Which is if string compare a with b is equal then do X. [if (strcmp(a,b) == 0)] Well, we're clearly into IMO land here, so lets ignore that :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
In message: p05101510b8ac2005b34b@[128.113.24.47] Garance A Drosihn [EMAIL PROTECTED] writes: : At 7:49 PM +0100 3/6/02, Poul-Henning Kamp wrote: : Garance A Drosihn writes: : In one message, : At 12:52 AM -0800 3/6/02, David O'Brien wrote: : I don't think it is clarifying a rule. I think it is in fact adding : a rule. You are extrapolating too much I think. All the rule is : trying to prevent is if (!strcmp(a,b)) which when read is extremely : wrong of that is actually happening. : : If we change boolean to integer, then the proposed rule will not : prevent if (!strcmp(a,b)) , because strcmp() *does* return an : integer value. Or am I missing something here? : : Right, and since the integer is well defined, : if (!strcmp(a, b)) : is perfectly understandable so what is the problem ? : : Well, that's my question. David's comment implies that it is not : good to do '!strcmp()', and I was wondering why it is not good... if (strcmp()) is the problem with if (!strcmp()) Which one is right? The first one should mean are the same but really means are different and likewise for the second one. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
In message [EMAIL PROTECTED], M. Warner Losh writes : : Well, that's my question. David's comment implies that it is not : good to do '!strcmp()', and I was wondering why it is not good... if (strcmp()) is the problem with if (!strcmp()) Which one is right? The first one should mean are the same but really means are different and likewise for the second one. Guys, strcmp() has been defined that way for almost 30 years, get used to it, and don't demand obfuscation of every other if() in the kernel to try to hide the fact... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
On Thu, Mar 07, 2002 at 07:14:49AM +0100, Poul-Henning Kamp wrote: Guys, strcmp() has been defined that way for almost 30 years, get used to it, and don't demand obfuscation of every other if() in the kernel to try to hide the fact... We are not trying to hide anything. Style(9) says to don't do that, so we shouldn't. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RFC: style(9) isn't explicit about booleans for testing.
The following is the largest part of the audit trail of PR docs/28555.
At the end of the audit trail, Dima Dorfman asked Mike Meyer to seek review
and comments from a wider audience than -doc. Since this documentation PR
has been open for quit some time now, I'm posting the patch the PR was
about, hoping to get comments from our style(9) meisters, and everyone else
that can help with this.
Giorgos Keramidas FreeBSD Documentation Project
keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/
--- Audit trail ---
On 2001-06-30 21:26, Mike Meyer wrote:
The style(9) page says not to use ! for testing values unless the
value is a boolean. It also says to test pointers against NULL. This
leaves open the question of how other values that aren't booleans
should be tested.
How-To-Repeat:
Read the man page to try and decide if you should write if (x) or
if (x != 0).
Fix:
Apply the attached page to the style(9) man page.
--- /usr/src/share/man/man9/style.9 Fri May 18 07:27:37 2001
+++ style.9 Sat Jun 30 16:23:34 2001
@@ -449,14 +449,37 @@
!(p = f())
.Ed
.Pp
-Don't use '!' for tests unless it's a boolean, e.g. use
+For tests, always compare the value to the appropriate 0 instead of
+checking it directly, unless the value is a boolean.
+For pointers, use:
+.Bd -literal
+if (p != NULL)
+.Ed
+.Pp
+not
+.PP
+.Bd -literal
+if (!p)
+.Ed
+.Pp
+For other values, use:
.Bd -literal
if (*p == '\e0')
.Ed
.Pp
not
.Bd -literal
-if (!*p)
+if (*p)
+.Ed
+.Pp
+unless the value is a boolean. In that case, use:
+.Bd -literal
+if (p)
+.Ed
+.Pp
+and
+.Bd -literal
+if (!p)
.Ed
.Pp
Routines returning void * should not have their return values cast
On 2002-06-30 21:57, Dima Dorfman wrote:
I think it is quite clear on the subject. If it's not a boolean,
don't treat it like one; i.e., compare it against the value you're
looking for. '0' may not always be that value.
Regardless, this does not belong as a PR, let alone in the docs/
category. It belongs as a post on -hackers, asking what people think,
not as a change request. Since *developers* are expected to follow
style(9), it is the *developers* (i.e., -hackers@) that you should be
proposing the change to.
On 2001-06-30 22:55, Mike Meyer wrote:
We both agree I'm not proposing a change in the style they have to
follow; I'm just proposing making something explicit instead of
implicit. As such, I'm not sure it warrants discussion. If the PR
belongs in another category, please feel free to move it to either
move it or suggest one for someone else to move it to.
On 2001-06-02 23:13, Dima Dorfman wrote:
I'm not suggesting that you should get every developer's approval, but
I am suggesting that wider review than the -doc list would be nice,
esp. for a document that defines policy.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
On Tue, 5 Mar 2002, Giorgos Keramidas wrote: Read the man page to try and decide if you should write if (x) or if (x != 0). Fix: Apply the attached page to the style(9) man page. [...] the one that I stop to think about is: if (!(flags FLAGSET)) or should that be if ((flags FLAGSET) == 0) it depends on what you define as a Boolean. If FLAGSET has 1 bit in it then it it still possibly a boolean? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
On 2002-03-05 12:59, Julian Elischer wrote:
On Tue, 5 Mar 2002, Giorgos Keramidas wrote:
Read the man page to try and decide if you should write if (x) or
if (x != 0).
Fix:
Apply the attached page to the style(9) man page.
[...]
the one that I stop to think about is:
if (!(flags FLAGSET))
or should that be
if ((flags FLAGSET) == 0)
it depends on what you define as a Boolean.
If FLAGSET has 1 bit in it then it it still possibly a boolean?
I was reading parts of the sys/netinet tree lately. Most of the
places I have seen so far use the second style, even for flags that
are stored in bitfields. Quoting ip_input.c:
if ((m-m_pkthdr.rcvif-if_flags IFF_LOOPBACK) == 0) {
ipstat.ips_badaddr++;
goto bad;
}
This is what I prefer too, but my own personal preference is probably
based on what I've seen so far, which is (I have to admit) very limited.
Giorgos Keramidas FreeBSD Documentation Project
keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
On Tue, Mar 05, 2002 at 10:13:50PM +0200, Giorgos Keramidas wrote: -Don't use '!' for tests unless it's a boolean, e.g. use +For tests, always compare the value to the appropriate 0 instead of +checking it directly, unless the value is a boolean. +For pointers, use: +.Bd -literal +if (p != NULL) +.Ed +.Pp +not +.PP +.Bd -literal +if (!p) +.Ed +.Pp +For other values, use: .Bd -literal if (*p == '\e0') .Ed .Pp not .Bd -literal -if (!*p) +if (*p) +.Ed +.Pp +unless the value is a boolean. In that case, use: +.Bd -literal +if (p) +.Ed +.Pp +and +.Bd -literal +if (!p) Please show examples from /sys that back up this change. To state this explicitly, I think a significant number of /sys files should be following it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
msg.pgp Description: PGP message
Re: RFC: style(9) isn't explicit about booleans for testing.
On Wed, Mar 06, 2002 at 02:08:07AM +0200, Giorgos Keramidas wrote: On 2002-03-05 15:58, David O'Brien wrote: On Tue, Mar 05, 2002 at 10:13:50PM +0200, Giorgos Keramidas wrote: -Don't use '!' for tests unless it's a boolean, e.g. use +For tests, always compare the value to the appropriate 0 instead of +checking it directly, unless the value is a boolean. ... Please show examples from /sys that back up this change. To state this explicitly, I think a significant number of /sys files should be following it. Actually I was asking for comments, but anyways. I was giving one. :-) style(9) documents the practices of /sys. Thus we should not arbitaryly add rules w/o them being backed up in code. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
In message: [EMAIL PROTECTED]
David O'Brien [EMAIL PROTECTED] writes:
: On Wed, Mar 06, 2002 at 02:08:07AM +0200, Giorgos Keramidas wrote:
: On 2002-03-05 15:58, David O'Brien wrote:
: On Tue, Mar 05, 2002 at 10:13:50PM +0200, Giorgos Keramidas wrote:
: -Don't use '!' for tests unless it's a boolean, e.g. use
: +For tests, always compare the value to the appropriate 0 instead of
: +checking it directly, unless the value is a boolean.
: ...
:
: Please show examples from /sys that back up this change. To state this
: explicitly, I think a significant number of /sys files should be
: following it.
:
: Actually I was asking for comments, but anyways.
:
: I was giving one. :-)
: style(9) documents the practices of /sys. Thus we should not arbitaryly
: add rules w/o them being backed up in code.
I believe that sys/pccard, sys/dev/{pccard,pcic,pccbb,cardbus} tends
to follow this rule. If you are looking for examples.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
David O'Brien [EMAIL PROTECTED] types: On Wed, Mar 06, 2002 at 02:08:07AM +0200, Giorgos Keramidas wrote: I was giving one. :-) style(9) documents the practices of /sys. Thus we should not arbitaryly add rules w/o them being backed up in code. As the original author of the PR, I'll point out that this chagne does *not* add rules. It clarifies the wording of a rule that's already there. If the rule is wrong, it should be removed. The reason I didn't post if for wider review was because it wasn't changing any rules. My thanks to Giorgos for moving this PR towards closure. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
In message [EMAIL PROTECTED], Mike Meyer writes:
David O'Brien [EMAIL PROTECTED] types:
On Wed, Mar 06, 2002 at 02:08:07AM +0200, Giorgos Keramidas wrote:
I was giving one. :-)
style(9) documents the practices of /sys. Thus we should not arbitaryly
add rules w/o them being backed up in code.
As the original author of the PR, I'll point out that this chagne does
*not* add rules. It clarifies the wording of a rule that's already
there. If the rule is wrong, it should be removed. The reason I didn't
post if for wider review was because it wasn't changing any rules. My
thanks to Giorgos for moving this PR towards closure.
I had a discussion with Eric Allman about this very thing recently
where he advocated everything inside if, while, for and so on should
be true booleans.
Now, IFF the C language had a type called boolean that would make
a lot of sense.
Unfortunately, it does not (at present ?) have a boolean type, and
while one could simulate it with typedefs, there is no way to get
the compiler to enforce the rule.
I belive the overall purpose of style(9) is to make the code readable,
and I happen to think that
if (somerandomfunction(argthis, functionthat(something), onemore)) {
chugchugchug(argthisa;
}
is just a tiny bit more readable than
if ((somerandomfunction(argthis, functionthat(something), onemore)
!= 0) {
chugchugchug(argthisa;
}
for instance.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
Poul-Henning Kamp [EMAIL PROTECTED] types:
In message [EMAIL PROTECTED], Mike Meyer writes:
David O'Brien [EMAIL PROTECTED] types:
On Wed, Mar 06, 2002 at 02:08:07AM +0200, Giorgos Keramidas wrote:
Now, IFF the C language had a type called boolean that would make
a lot of sense.
So you're advocating that the rule be dropped.
I belive the overall purpose of style(9) is to make the code readable,
and I happen to think that
if (somerandomfunction(argthis, functionthat(something), onemore)) {
chugchugchug(argthisa;
}
is just a tiny bit more readable than
if ((somerandomfunction(argthis, functionthat(something), onemore)
!= 0) {
chugchugchug(argthisa;
}
I agree with you. Under the rules as they exist now, the first form
would only be valid if somerandomfunctoin returned either 0 or true.
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
In message [EMAIL PROTECTED], Mike Meyer writes: Poul-Henning Kamp [EMAIL PROTECTED] types: In message [EMAIL PROTECTED], Mike Meyer writes: David O'Brien [EMAIL PROTECTED] types: On Wed, Mar 06, 2002 at 02:08:07AM +0200, Giorgos Keramidas wrote: Now, IFF the C language had a type called boolean that would make a lot of sense. So you're advocating that the rule be dropped. I'm advocating that the rule focus on readability rather than trying to enforce a type which doesn't exist. Type-enforcement is a task for the compiler, not for a manpage. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
