Hi Joerg,
Joerg Schilling píše v út 04. 05. 2010 v 12:22 +0200:
> Milan Jurik <milan.ju...@sun.com> wrote:
>
> > Joerg Schilling pí??e v po 03. 05. 2010 v 16:55 +0200:
> > > Milan Jurik <milan.ju...@sun.com> wrote:
> > >
> > > > > You may be able to agree with me on better thandards than the ones I
> > > > > currently
> > > > > use but you will not succeed to let me agree on inferior standards.
> > > > >
> > > >
> > > > Well, I do not consider ANSI C and other requirements sent by James
> > > > Carlson as "inferior". Which is the basic of our disagreement probably.
> > > > You can consider ON gate "C style" as not ideal but it is based on years
> > > > of experience of many contributors.
> > >
> > > From your wording, it seems that that you just do not understand me and
> > > that you simply missunderstand me because you did never look at my code.
> > > All my code makes advantages from ANSI C, most of the code in ON however
> > > does not make advantage from ANSI C.
> > >
> >
> > strnlen(s, len)
> > register const char *s;
> > register size_t len;
> >
> > I do not see this as good ANSI C.
>
> I am not sure whether you are the right person to discuss this.....
Probably not, feel free to stop whenever you will want to do so.
> This is the second time where you sent an unrelated reply.
> Did you read the mail you replied to?
>
Again, James Carlson asked you to use modern C style. I do not consider
old K&R style of function declaration as good in 2010. And it is against
"C style" requirements for new code included to ON gate. Yes, you are
using some parts of ANSI C in your code, but one of the key benefit you
are ignoring. And that part is requirement for all new code going to ON
gate. There are other comments you ignored already (not ANSI C, but for
good new code for ON gate).
> 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.
>
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
