If you compile the unmodified sources under usr/src/cmd/sh/ you get 262 warnings
for missing prototypes (even if you _disable_ warnings from Sun Studio) and if
you did fix this, you would see about 1000 new warnings caused by incorrect
parameters when calling functions. In addition, the ON version of the sh source
is not 64 bit clean and it will not work in multi-byte locales on other UNIX
systems as the mb*() functions are called making incorrect assumptions on the
behavior of the multibyte support functions.
I always compile all my code with warnings _enabled_ and If you compile my
version
of the Bourne Shell, you see not a single warning although the function
implementations look like (see example from args.c):
int
options(argc, argv)
int argc;
unsigned char **argv;
{
unsigned char *cp;
My version compiles (as mentioned above) without a single warning with Sun
Studio _and_ with the highest warning level from gcc and my version is 64 bit
clean. My version runs on most known platforms and it does so even on
multi-byte locales.
I'm probably going to regret stepping into this mess... but here goes.
The above declaration is certainly superior to functions that lack an
explicit argument list. So from that perspective Joerg is correct, this
is better, and the legacy sh code is in need of some lovin'.
However, Milan is correct to say that in OpenSolaris we have (for quite
a long time now) used ANSI style prototypes rather than K&R prototypes.
Furthermore, there are no more platforms in common use which require K&R
C. After all, the ANSI C spec was ratified a *long* time ago. (1989?)
Finally, for code that is "integrated" into ON, we are kind of sticklers
about making that code "native". That is to say, new code should adhere
to ON coding styles, lint rules, etc. It is possible to get exceptions
(ala ksh93), but there have to be strong motivations. (In ksh93 the
argument goes that the code base was quite large, has a large upstream
contributor base, is actively maintained by the same large community,
and there are no other viable alternatives. Even so, this particular
case has been a continued source of contention -- see for example the
complaints some months ago when I suggested that Sun/Oracle might need
to make changes to the integrated ksh93 that are not incorporated
upstream. The furor over that still makes my head hurt.)
Btw, during code reviews, I also generally insist that "portability"
macros and other similar mechanisms to support other platforms be
removed prior to code integration. Why? Because we *know* what our
platform is, and we have no way of testing the code that is #ifdef'd
out. In general, I am opposed to integration of code that is never
compiled on Solaris, and I believe that most of other gatekeepers and
code reviewers share this sentiment. (Note that this paragraph only
applies to ON. Code that more closely follows an upstream source can be
integrated into SFW -- or even better, /contrib, without requiring many
of these changes.)
Upshot of all this is, its far, far easier to follow the guidelines and
integrate code that follows the current rules. Pointing out the other
bad examples (legacy sh, or even ksh93) won't get you anything except
increasing overall resentment.
If you want to integrate code into OpenSolaris, then you should step up
here and take on some of the work required and argue less -- the
sponsorship duties are already burdensome enough without asking folks to
volunteer to "convert your code" or deal with the flame wars that tend
to happen around your (Joerg) postings.
Of course, nobody is requiring you to do any of these things. But then
again, I'm not aware of any significant demand from anyone other than
you (Joerg) that any of your code be integrated.
On a final note, it seems that anyone can submit a package using
SourceJuicer for integration into /contrib. (I'm not sure who the
"Approvers" are that promote a package from /pending to /contrib...) I
don't see star in /contrib. Have you submitted a SourceJuicer package
for it? If not, why not? That is work you could do entirely on your
own.... see http://jucr.opensolaris.org/help/sjhowto
-- Garrett
Warnings and "C style" are different topics. The source code can be
warning and error free and still it will not be good enough to be
included to ON gate (because it is not only about contribution, somebody
will need to read that code).
Yes, I agree that ON gate is not using all warning tests available in
compiler and lint and I see it as mistake but still (personal experience
showing we would avoid at least several unpleasant bugs if we would not
disable these warning tests), "C style" requirement is part of policy
and I see consistent "C style" as important requirement.
Do you still believe that what you ask me to do is superior to what I already
do?
Yes, I believe so.
Do you still believe that I am not using prototypes?
Where did I write you are not using prototypes? I wrote you are using
old style function declarations and it is bad to use them and prohibited
for new code in ON gate.
You should face that the only visible effect of "requirements" like the one
mentioned by James is to prevent contributions from people outside of Oracle.
Maybe it can be barier for somebody to write properly "C-styled" source
code. However I believe it is not real barier for somebody willing to
contribute.
Given the fact that SunOS is supposed to support 64 bit since 1997, it seems
that a lot of code was neglected and not touched since more than 13 years.
If you like to give Solaris a future, you need to allow contributions that
raise the code quality.
You ignored the rest of my e-mail, so I am citing my own words from it
again:
"If you want to contribute, then contribute in way of rules for
contributions. This is basic rule of every software project (open source
or closed source)."
I have no more arguments and if you will not bring new, I will stop to
contribute to this e-mail thread because it went to neverending
flamewar.
Jörg
Best regards,
Milan
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
