From: Ivan Gyurdiev <ivg2@cornell.edu>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Karl MacMillan <kmacmillan@tresys.com>,
selinux@tycho.nsa.gov, "'Joshua Brindle'" <jbrindle@tresys.com>
Subject: Re: [PATCH] semanage-functionality 4/17
Date: Fri, 30 Sep 2005 09:02:54 -0400 [thread overview]
Message-ID: <433D377E.6090700@cornell.edu> (raw)
In-Reply-To: <1127854647.21671.194.camel@moss-spartans.epoch.ncsc.mil>
>Yes, and I'm dubious that such elimination is practically useful; you
>still have to audit the code for correct usage and in any case where it
>affects an exposed interface, you have the whole stable API/ABI issue to
>deal with.
>
>
Struct pointer typedefs eliminated in favor of consistency. See patches.
>
>
>>Then we'll have to type struct everywhere...
>>
>>
>
>Yes, I see it as a benefit to be able to easily see from the code
>whether a function (and the code) is dealing with a pointer or a struct
>without needing to look up a separate type definition. Think in terms
>of long term code maintainability / readability, particularly for
>patches. Besides, typing "struct foobahblaz" isn't so much worse than
>typing "foobahblaz_t". The kernel maintainers are right on the issue of
>typedefs...
>
>
Todo. I am less excited about removing the _t types - I don't like
typing struct... You can now see whether you are dealing with a pointer
or struct...because there are no more pointer typedefs...so there's a
star everywhere, meaning pointer. I'm not sure that was a good idea, but
at least it's consistent, which is much better than being inconsistent
(of course, we could have tried to go the other way instead too...).
--
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.
next prev parent reply other threads:[~2005-09-30 13:02 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-27 12:46 [PATCH] semanage-functionality 4/17 Karl MacMillan
2005-09-27 16:54 ` Ivan Gyurdiev
2005-09-27 20:08 ` Stephen Smalley
2005-09-27 20:48 ` Ivan Gyurdiev
2005-09-27 20:57 ` Stephen Smalley
2005-09-30 13:02 ` Ivan Gyurdiev [this message]
2005-09-30 13:47 ` Karl MacMillan
2005-09-28 15:21 ` Karl MacMillan
2005-09-27 20:38 ` Karl MacMillan
2005-09-27 21:06 ` Ivan Gyurdiev
2005-09-27 21:10 ` Stephen Smalley
2005-09-28 15:15 ` Karl MacMillan
2005-09-28 14:52 ` Stephen Smalley
2005-09-28 15:21 ` Ivan Gyurdiev
2005-09-28 15:33 ` Karl MacMillan
2005-09-28 15:31 ` Karl MacMillan
2005-09-28 15:59 ` Stephen Smalley
2005-09-28 16:24 ` 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=433D377E.6090700@cornell.edu \
--to=ivg2@cornell.edu \
--cc=jbrindle@tresys.com \
--cc=kmacmillan@tresys.com \
--cc=sds@tycho.nsa.gov \
--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.