All of lore.kernel.org
 help / color / mirror / Atom feed
From: Karl MacMillan <kmacmillan@mentalrootkit.com>
To: Brian Pomerantz <bapper@piratehaven.org>
Cc: selinux@tycho.nsa.gov
Subject: Re: [PATCH] Basic policy representation
Date: Tue, 08 May 2007 15:41:20 -0400	[thread overview]
Message-ID: <1178653280.3155.6.camel@localhost.localdomain> (raw)
In-Reply-To: <20070508164741.GA29479@skull.piratehaven.org>

On Tue, 2007-05-08 at 09:47 -0700, Brian Pomerantz wrote:
> On Tue, May 08, 2007 at 12:11:11PM -0400, Karl MacMillan wrote:
> > On Tue, 2007-05-08 at 11:48 -0400, Joshua Brindle wrote:
> > > Karl MacMillan wrote:
> > > > On Tue, 2007-05-08 at 10:45 -0400, Joshua Brindle wrote:
> > > >   
> > > >> Karl MacMillan wrote:
> <snip>
> > > >> is it really necessary to use a char here? granted its smaller but it 
> > > >> also doesn't really convey to someone new to the code what is going on. 
> > > >> Perhaps a bool typemap? or short int?
> > > >>
> > > >>     
> > > >
> > > > Char isn't necessary, though I think it is a common idiom to use char as
> > > > boolean in C programs. What do you mean by typemap (typedef?). I don't
> > > > really think that short int is any better.
> > > >
> > > >   
> > > 
> > > oops, I meant typedef.
> > > 
> > 
> > I've worked on codebases with and without boolean typedefs and
> > personally prefer to not have a typedef. Any other opinions?
> > 
> 
> Using the standard *nix form of returning int is always safe and
> consistent.
> 

I actually prefer returning char instead - to me that is a common way to
indicate that the returned value has a limited range of values (2 in
this case). But maybe that is just the code bases I've worked on. I
don't care either way - this seems like a bike shed discussion . . .

Karl


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

  reply	other threads:[~2007-05-08 19:50 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-07 22:06 [PATCH] Basic policy representation Karl MacMillan
2007-05-08 14:45 ` Joshua Brindle
2007-05-08 15:08   ` Karl MacMillan
2007-05-08 15:48     ` Joshua Brindle
2007-05-08 16:11       ` Karl MacMillan
2007-05-08 16:47         ` Brian Pomerantz
2007-05-08 19:41           ` Karl MacMillan [this message]
2007-05-09 14:03             ` Karl MacMillan
2007-05-11 15:27               ` Joshua Brindle
2007-05-11 18:45                 ` Karl MacMillan
2007-05-08 17:13         ` Stephen Smalley
2007-05-08 18:37           ` Joshua Brindle
2007-05-08 19:05             ` Stephen Smalley
2007-05-08 19:28               ` Joshua Brindle
2007-05-08 19:36                 ` Karl MacMillan
2007-05-08 16:50   ` Stephen Smalley
2007-05-09 16:24 ` James Antill
2007-05-09 18:31   ` Karl MacMillan
2007-05-09 18:35 ` J. Tang
2007-05-09 19:22   ` Karl MacMillan
2007-05-09 22:46     ` J. Tang
2007-05-09 23:26       ` Karl MacMillan
2007-05-10 19:42         ` J. Tang
2007-05-10 20:00           ` Karl MacMillan
  -- strict thread matches above, loose matches on Subject: below --
2007-05-10 17:56 Karl MacMillan

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=1178653280.3155.6.camel@localhost.localdomain \
    --to=kmacmillan@mentalrootkit.com \
    --cc=bapper@piratehaven.org \
    --cc=selinux@tycho.nsa.gov \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.