util-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Karel Zak <kzak@redhat.com>
To: Mike Frysinger <vapier@gentoo.org>
Cc: kerolasa@gmail.com, util-linux <util-linux@vger.kernel.org>
Subject: Re: [PATCH 1/7] zramctl: print all devices as a default action
Date: Wed, 6 Aug 2014 10:16:02 +0200	[thread overview]
Message-ID: <20140806081602.GG19820@x2.net.home> (raw)
In-Reply-To: <1946062.6JF60ZCY1D@vapier>

On Mon, Aug 04, 2014 at 03:31:13AM -0400, Mike Frysinger wrote:
> On Sun 03 Aug 2014 21:50:33 Sami Kerola wrote:
> i think there should be more.  i find them more readable, clearer intent, and 
> harder to screw up.  whereas passing around 0/1 everywhere gets funky (and i 
> think the code looks funky already).
> 
> > util-linux> git grep -l 'bool '
> > lib/mbsalign.c
> > login-utils/su-common.c
> > sys-utils/hwclock-cmos.c
> > sys-utils/hwclock.c
> > sys-utils/nsenter.c
> > tests/ts/login/logindefs
> > 
> > And question about bool is asked before.
> > 
> > http://marc.info/?l=util-linux-ng&m=135817763904699&w=2
> 
> it's a little hard to tell if it was meant generally or that specific case.  
> but if Karel prefers they not be used, then the codebase should reflect that.

I don't have strong opinion against 'bool', but I personally don't use
it. Well, exception are public library APIs, where the bool type is
mistake IMHO. 

The 'bool' type is gray C zone in some cases.

        slcurses.h:#define bool int
        python2.7/asdl.h:typedef enum {false, true} bool;

        tirpc/rpc/types.h:typedef int32_t bool_t;
        ncurses.h:#define bool NCURSES_BOOL
        notmuch.h:typedef int notmuch_bool_t;

 .. or bool, true and false are macros and bool expands to build-in C99 
 _Bool type or it's keyword in C++, etc.


For me "func(int isbar)" has the same readability as "func(bool bar)"
and in structs is always better to use bit fields (arrays).

> > The question was never answered, but if I should guess the idea in
> > util-linux is same as what Linus said should be done in kernel.
> > 
> > https://lkml.org/lkml/2013/8/31/138

Thanks, I have never read this, but he is right :-)

It seems that it's nothing unusual that people fight with bool in C:
http://www.lysator.liu.se/c/c-faq/c-8.html
http://stackoverflow.com/questions/25461/interfacing-with-stdbool-h-c
https://www.gnu.org/software/gnulib/manual/html_node/stdbool_002eh.html

And I don't think that codebase should reflect all my opinions :-)

Note, please, don't send patches that only remove/add bool -- common
sense is better than rules, if you believe that bool is the best thing
for your code than use it (if you cannot use bit fields, bool in
structs will be rejected). I'm going to use 'int' in my code.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

  reply	other threads:[~2014-08-06  8:16 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-03 14:17 [PATCH 1/7] zramctl: print all devices as a default action Sami Kerola
2014-08-03 14:17 ` [PATCH 2/7] docs: add details to zramctl --size option documentation Sami Kerola
2014-08-03 14:17 ` [PATCH 3/7] zramctl: mark --reset mutually exclusive with --algorithm and --streams Sami Kerola
2014-08-03 14:17 ` [PATCH 4/7] zramctl: fail status printout when device does not exist Sami Kerola
2014-08-03 14:17 ` [PATCH 5/7] zramctl: improve error message Sami Kerola
2014-08-03 14:17 ` [PATCH 6/7] zramctl: fix mount point printout Sami Kerola
2014-08-04 12:15   ` Karel Zak
2014-08-05 23:03     ` Sami Kerola
2014-08-03 14:17 ` [PATCH 7/7] zramctl: add bash completion script Sami Kerola
2014-08-03 14:50 ` [PATCH 1/7] zramctl: print all devices as a default action Mike Frysinger
2014-08-03 20:50   ` Sami Kerola
2014-08-04  7:31     ` Mike Frysinger
2014-08-06  8:16       ` Karel Zak [this message]
2014-08-03 22:19 ` Bernhard Voelker
2014-08-04 12:02 ` Karel Zak
2014-08-05 22:38   ` Sami Kerola
2014-08-11 12:49 ` Karel Zak

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=20140806081602.GG19820@x2.net.home \
    --to=kzak@redhat.com \
    --cc=kerolasa@gmail.com \
    --cc=util-linux@vger.kernel.org \
    --cc=vapier@gentoo.org \
    /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).