linux-kernel - Re: [Tux3] Tux3 report: Tux3 Git tree available

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200903121947.58367.nickpiggin@yahoo.com.au>
Date:	Thu, 12 Mar 2009 19:47:57 +1100
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Daniel Phillips <phillips@...nq.net>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, tux3@...3.org,
	linux-kernel@...r.kernel.org
Subject: Re: [Tux3] Tux3 report: Tux3 Git tree available

On Thursday 12 March 2009 19:33:02 Daniel Phillips wrote:
> On Wednesday 11 March 2009, Andrew Morton wrote:

> > > Obviously, that raises the question of whether C99 syntax is banned in
> > > kernel.
> >
> > It is banned ;)
> >
> > I'm not sure why, really - I have vague memories of Linus having an
> > episode...  It seems an OK construct if used tastefully.  Although it
> > does make it easy to hide nasty surprises.
> > ...
> > Well.  As I say, it doesn't bother me much (but I like C++, so ignore
> > me).  But it will make merge/review life harder for you at the outset.
> > How much harder I cannot predict.  People will fixate on this issue
> > at the expense of everything else..
>
> Well, I suppose we will do something in the middle for now: change some
> to K&R, and leave some of it as is where we expect it to be developed
> heavily, like dleaf.c which is going to see whole bunch of work to
> integrate versioning, so it really makes little sense to make it harder
> to factor just before starting that work.  Anyway, the C++ comments are
> on their way out and after all that is the one people love to hate.

I think they need to be fixed before merge. If the function is easier
to follow when you use this feature, IMO it indicates the function is
too big or badly written anyway.


> There are a couple of issues, one is u64 being (long) instead of
> (long long) as you say, and the other is variable type sizes like
> loff_t.  That specific one isn't actually a problem, we can just refuse
> to support 32 bit libc file ops, but there may be others.  We had a
> world of pain before (L) arrived, then with (L) it was easy.  Maybe
> just edit them all to (long long) for now, and damn the line length.

Yes please do this. A significant style change like this that lots of
code already does I think is best first discussed as a standalone
change to kernel rather than everyone developing their own convention.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/