On Thursday 12 March 2009 20:00:18 Daniel Phillips wrote: > Hi Nick, > > On Thursday 12 March 2009, Nick Piggin wrote: > > 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. > > It's not about being easier to follow as being easier to factor. Putting > the variables far away from point of use increases the busy work in > moving code around significantly, with a corresponding reduction in code > quality in the long run, because time is spent fiddling with declarations > instead of improving structure. That said, it no doubt will be changed
Again, I would say if it takes so much more work to maintain, then the functions are too big or badly written. But I guess it is a matter of opinion, so... > before merge. Not that I think there is a sensible reason for it, but > because it makes little sense to dig in over a cosmetic issue. ... how about because it follows agreed convention? > > > 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. > > That will be in the next batch of changes. So... we offered our shiny > new convention, and I consider it voted down. All in a days work :) Cool. Maybe if you offer it as a standalone patch to the kernel, it will get more attention? It's just not appropriate to put in with a new filesystem. _______________________________________________ Tux3 mailing list [email protected] http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3
