linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: John Reiser <jreiser@bitwagon.com>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [RFC][PATCH 01/11] ftrace/trivial: Clean up recordmcount.c to use Linux style comparisons
Date: Fri, 22 Apr 2011 12:13:46 -0400	[thread overview]
Message-ID: <1303488826.6225.9.camel@gandalf.stny.rr.com> (raw)
In-Reply-To: <4DB19A1E.8070806@bitwagon.com>

On Fri, 2011-04-22 at 08:09 -0700, John Reiser wrote:
> On 04/20/2011 07:28 PM, Steven Rostedt wrote:
> > From: Steven Rostedt <srostedt@redhat.com>
> > 
> > The Linux style for comparing is:
> > 
> >   var == 1
> >   var > 0
> > 
> > and not:
> > 
> >   1 == var
> >   0 < var
> > 
> > It is considered that Linux developers are smart enough not to do the
> > 
> >   if (var = 1)
> > 
> > mistake.
> 
> It's not just a matter of 'smart', it's a matter of safety.
> For me it still catches a bug (typo, copy+paste, fumble in editor script, ...)
> every year or two.  Compilers haven't always warned, or the option to warn
> might be turned off.


I totally understand why it is used. But personally, it confuses my
train of thought when reading code. That notation is just a work around
to a deficiency in the C language. And I find the time spent trying to
decipher 0 == var takes up much more time than debugging if (var = 0).

Although, I have no idea why you choose the 0 < var, that totally
confuses me. It does not play any role in assignments. What bug is that
preventing? When I want to know if a variable is greater than zero, I
don't show it as zero less than the var.

> 
> > -	return 0 == strcmp(".text",           txtname) ||
> > +	return strcmp(".text",           txtname) == 0 ||
> 
> I consider "0==strcmp(" to be an idiom.  Too often "strcmp(...) == 0"
> overflows my mental stack because of the typographic width of the operands
> in the source code.  If you still object in this case then please consider
> using something like:
> 	#define strequ(a,b) (strcmp((a), (b)) == 0)
> or
> 	static int strequ(char const *a, char const *b)
> 	{
> 		return strcmp(a, b) == 0;
> 	}
> which names the idiom.

I'm all for making a streq. Perhaps that could be a nice clean up of the
kernel. It definitely makes it much easier to read and understand. But
that is for another time.

As I'm working on this code, and I'm the maintainer, I want to make sure
I can read and review the code easily. Anything that distracts me for
other people's personal taste, is something that I don't have the luxury
of time for. Thus, I'm keeping these patches as is for the time being.

-- Steve




  parent reply	other threads:[~2011-04-22 16:13 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-21  2:28 [RFC][PATCH 00/11] ftrace/recordmcount: Remove useless mcount calls not being traced Steven Rostedt
2011-04-21  2:28 ` [RFC][PATCH 01/11] ftrace/trivial: Clean up recordmcount.c to use Linux style comparisons Steven Rostedt
2011-04-21  8:46   ` Alan Cox
2011-04-21 11:36     ` Steven Rostedt
2011-04-21 12:28       ` Steven Rostedt
2011-04-22 15:09   ` John Reiser
2011-04-22 15:52     ` Thiago Farina
2011-04-22 16:05       ` Steven Rostedt
2011-04-26 18:52         ` Thiago Farina
2011-04-26 19:09           ` Steven Rostedt
2011-04-22 16:13     ` Steven Rostedt [this message]
2011-04-22 17:40       ` John Reiser
2011-04-22 17:56         ` H. Peter Anvin
2011-05-18 18:31   ` [tip:perf/core] " tip-bot for Steven Rostedt
2011-06-16 14:04   ` tip-bot for Steven Rostedt
2011-04-21  2:28 ` [RFC][PATCH 02/11] ftrace/trivial: Clean up record mcount to use Linux switch style Steven Rostedt
2011-05-18 18:31   ` [tip:perf/core] " tip-bot for Steven Rostedt
2011-06-16 14:04   ` tip-bot for Steven Rostedt
2011-04-21  2:28 ` [RFC][PATCH 03/11] ftrace: Add .kprobe.text section to whitelist for recordmcount.c Steven Rostedt
2011-05-18 18:32   ` [tip:perf/core] " tip-bot for Steven Rostedt
2011-06-16 14:05   ` tip-bot for Steven Rostedt
2011-04-21  2:28 ` [RFC][PATCH 04/11] ftrace/recordmcount: Modify only executable sections Steven Rostedt
2011-05-18 18:32   ` [tip:perf/core] " tip-bot for Steven Rostedt
2011-06-16 14:05   ` tip-bot for Steven Rostedt
2011-04-21  2:28 ` [RFC][PATCH 05/11] ftrace/recordmcount: Make ignored mcount calls into nops at compile time Steven Rostedt
2011-05-18 18:32   ` [tip:perf/core] " tip-bot for Steven Rostedt
2011-06-16 14:05   ` tip-bot for Steven Rostedt
2011-04-21  2:28 ` [RFC][PATCH 06/11] ftrace/recordmcount: Add warning logic to warn on mcount not recorded Steven Rostedt
2011-05-18 18:33   ` [tip:perf/core] " tip-bot for Steven Rostedt
2011-06-16 14:06   ` tip-bot for Steven Rostedt
2011-04-21  2:28 ` [RFC][PATCH 07/11] kbuild/recordmcount: Add RECORDMCOUNT_WARN to warn about mcount callers Steven Rostedt
2011-04-21  2:40   ` Steven Rostedt
2011-04-21 20:40   ` Michal Marek
2011-04-26 19:08     ` Steven Rostedt
2011-05-18 18:33   ` [tip:perf/core] " tip-bot for Steven Rostedt
2011-06-16 14:06   ` tip-bot for Steven Rostedt
2011-04-21  2:28 ` [RFC][PATCH 08/11] ftrace: Avoid recording mcount on .init sections directly Steven Rostedt
2011-05-18 18:34   ` [tip:perf/core] " tip-bot for Steven Rostedt
2011-06-16 14:07   ` tip-bot for Steven Rostedt
2011-04-21  2:28 ` [RFC][PATCH 09/11] ftrace/x86: Do not trace .discard.text section Steven Rostedt
2011-05-18 18:34   ` [tip:perf/core] " tip-bot for Steven Rostedt
2011-06-16 14:07   ` tip-bot for Steven Rostedt
2011-04-21  2:28 ` [RFC][PATCH 10/11] ftrace/recordmcount: Remove duplicate code to find mcount symbol Steven Rostedt
2011-05-18 18:34   ` [tip:perf/core] " tip-bot for Steven Rostedt
2011-06-16 14:07   ` tip-bot for Steven Rostedt
2011-04-21  2:28 ` [RFC][PATCH 11/11] ftrace/recordmcount: Add helper function get_sym_str_and_relp() Steven Rostedt
2011-05-18 18:35   ` [tip:perf/core] " tip-bot for Steven Rostedt
2011-06-16 14:08   ` tip-bot for Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1303488826.6225.9.camel@gandalf.stny.rr.com \
    --to=rostedt@goodmis.org \
    --cc=akpm@linux-foundation.org \
    --cc=fweisbec@gmail.com \
    --cc=hpa@zytor.com \
    --cc=jreiser@bitwagon.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).