Hi Joerg, Joerg Schilling píše v ne 02. 05. 2010 v 22:50 +0200: > Milan Jurik <[email protected]> wrote: > > > Hi Joerg, > > > > Joerg Schilling pí??e v so 01. 05. 2010 v 19:17 +0200: > > > James Carlson <[email protected]> wrote: > > > > > > > > You Most of the code I see from Sun does not follow > > > > > these rules and the variable names are of course OK in a piece of > > > > > code that > > > > > is easy to read (all string sources in ON use tose 's' variables..... > > > > > Note that K&K function _implemetations_ are needed for portability > > > > > and that > > > > > there is no benefit from using ANSI C here as there are ANCI C > > > > > function > > > > > _declarations_. > > > > > > > > > > I hope you know the difference between a function "declaration" and a > > > > > function > > > > > "implementation". > > > > > > > > Read the C style guide on the web site and try again. > > > > > > Irrelevant as long as nearly all current code in ON is similar to mine. > > > > > > > There is a lot of code in ON gate which was written and integrated > > before "C style" was published. Such code is improved if the relevant > > part of source code is touched. Nobody will invest time to reformat all > > at once, of course. But including new code with different "C style" will > > not make the "C style" of ON gate better, but worse. > > > > Even some new code introduced to the ON gate is not following the "C > > style". I know two reasons for it (maybe there are others): > > I am sorry but these so called "requirements" cannot be discussed as they are > a > step backwards. What James asked me to do is not based on technical > requirements > but just rather burocratic. >
Yes, they can be seen as burocratic. But ON gate source code is "maintained" by hundreds of developers for more than 20 years. If everybody will use own C style I would give up my job as sustanining engineer because the code would be unreadable (and it is faaar from perfect these days). Every project has own set of "requirements", in case of ON gate it is (not only) "C style" set nearly 20 years ago. > My code meets all the thechnical requirements that are behind what James > asked > me to do, so there is no need for a change. The main difference is that I am > writing portable code and the code in ON is non-portable. I will of course > not > give up the portability of my code. > What is the benefit to have portable code in ON gate if it will bring a lot of new header files, new framework, new ifdefs (not your case but others are doing that)? ON gate will be bigger, compilation slower, maintainance larger. All for "system level code" and those part not significant for ON gate would consume the space only. Your proposed fixes are significant but they have small size. Why should ON gate accept such code changes? There are examples of code not following the "C style" in ON gate and believe me, if I need to touch such code, I am not happy man (and not only I). > If you are interested in a collaboration, you could get a lot of interesting > things from me as I did e.g. take old code from Sun and did rewrite it in > order to make it portable and in order to convert it to modern code that e.g. > provides prototypes for _all_ functions. I am sure that if you are interested > in the future of Solaris, you will be interested in using my enhanced code. > All my code is also correctly working when compiled for 64 bits, Sun's > majority > of the code is definitely missbehaving if compiled for 64 bits. > Which would be very good to have, of course. > I am willing to provide enhanced code for "sh", "diff" and "sccs" interested? > Well, there is interest in it I believe. But in the style of code and the framework of ON gate. I understand you do not want to maintain two different code bases. Well, find somebody who is willing to take your proposed changes and rewrite them to be ideal parts of ON gate and push them through the process. Hopefully there is some member of OSol community willing to do that. > Jörg > Best regards, Milan _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
