http://www.newsforge.com/programming...6.shtml?tid=25


This has once been suggested a few times before on the Internet. I do
think it is a very good idea!

My main concern is with the quality of code being contributed to the
Linux Open Source pool. The applications works with small set of
features. When trying to compile it there are a warning messages flying
past the screen. This is true even with the Linux Kernel compile. This
suggests that:

-The Linux programmer only knows how to implement the function but does
not know the C programming language well. Their knowledge in pointer
usage, global variable usage, union, types and function parameters is not
good.

In Software Engineering classes it is a well know maxim, "You can prove
the presence of bugs but you cannot prove their absence." A clean
compile is atleast a lot better than a screen full of warning messages.
While that it may not prove the absence of bugs, it certainly is the
closest thing to reliablility.

Rewarding programmers to clean up the code is a great way to create a
robust OS and applications. A prize of $200 to clean up the code for
GNOME XYZ application OR Linux Network drivers, is a lot of money for a
programmer in India. Similar prizes could be setup to clean the code for
the kernel, KDE, OpenOffice etc.

The reward for any application/system should have a definite deadline and
should meet the code documenting standards. It should have a basic
standard for the "Makefile" and compiler options. For example, the
"Makefile" should not have "2>&1 > /dev/null" for the file compile.

The Linux kernel 2.6 compile is a lot better. There are still tons of
warning messages that fly by the screen. Doesn't this raise the concern
about buffer overflow problems in those drivers or modules?

Accept it or not, the truth is that the Open Source developer will not
hang on to the same project for the rest of his/her life. If there is a
better opportunity he/she will leave their "baby" for the world to take
care of it. A crude analogy would be someone doing odd jobs for whatever
reason. Once there is a better opportunity, the odd job is history.
Open Source developing is more like an "odd" job for these programmers.
Whatever great things that they have contributed should be cleaned up.
With giving some financial reward it can be accomplished. For example
the GNOME's "Bounty" system is a great idea to add features to a product!

My personal observation (being a command line afficianado) is that the
Windows environment on Linux is so Bloated (with a capital "B"), it makes
Windows look like a great champ. Suddenly, using KDE apps or GNOME apps
on Linux doesn't seem to be too attractive. Besides when I tried to
build them there were tons of warning messages which does make me
nervous, for any possible buffer overflow problems.

"Paying developers to get features fast" is the way to go for Open Source
movement. "For the love of coding" is a temporary truth for the coder.
When reality hits with bills to pay, then that love is gone. The code
can be cleaned up by many other "C" linguists at a great deal. I am sure
that if a 1000 Linux users around the world give $1 each to clean up code
in the Linux Kernel or GNOME or KDE, then that is $1000 prize amount.
That is a LOT of money for a teenager in Germany or a small group of
progammers in India. Everyone benefits with this approach.

The "clean compile" should be demonstarted on atleast 5 major
distributions. That is the proof of some good work and money well
earned.

The required infrastructure is already in place. For example,
sourceforge.net is a great place to start.

This is a great article and people should pay more attention to it!

BT

On Wed, 21 Jan 2004 21:41:54 GMT, Ben Theil <noname@nowhere.net>
wrote:

interesting article on how some software houses base their products on
existing Open Source, rather than starting from scratch.
integers for almost everything. What is seen by some as warnings is
seen by others as shortcomings of th compiler. It works, and works
well.
documented testing is one that springs to mind.
can get rid of the compiler warnings... the tell you what they're
complaining about!
You mean that the other way round??? Otherwise stderr is displayed on
stdout, and stdout is discarded.
is generated is of a far higher quality than most commercial products,
where people develop what they're told. OK, real life gets in the way,
but you're never going to make a living out of it are you. So the
difference is between unpaid and paid work that you do in your spare
time. Which one will be of better quality???
overflows??? Makes no sense to me.
out of a software sweatshop in India or anywhere else for that matter.
against different distros proves that all library calls are standard,
and nothing else ( major that I can think of at the moment! ).
$0.02 from an old f*rt who's just been in the industry too long!

Ben Theil wrote:
not even mean errors in the code. They just alert you to the fact that
you need to keep an eye on certain parts of your code to make sure they
do what you want them to do.

Many code optimisations generate warnings but the programmer knows best,
and only the programmer can decide whether or not the code does what
he/she wants it to do, as always.

To suggest that a certain programmer doesn't know the ins and outs of
C/C++ because GCC threw some warnings is at best ignorant and offensive.


Conversely, having no warning messages doesn't mean that your code has
fewer bugs.

few I can think of:

How do you judge the "winner" of the prize? What happens to all the
other attempts at "clean code"? It sounds a lot like "You do such and
such, and I might pay you". Not very attractive, even to the poorest of
people.

Now you might say it would work similarly to how other software
competitions are done. The problem is, free-software programmers enjoy
writing free software because
a.) The software has never been written or thought possible before.
b.) The software gives them recognition of their programming skills.
c.) The software will forever have bug fixes and features added for as
long as people use it.
The lure of the competition is in the winning, not necessarily the
prize. The prize just increases the amount of time they are prepared to
spend on the project. Cleaning somebody else's code is about as
attractive as cleaning your neighbor's toilet.

Frequently, cleaning bad code means rewriting it. Rewriting code is the
same as making new code - there will be a whole other can of bugs,
pardon my pun. If it works leave it alone.

The alternative is to accept only clean code into the project. This is
very often the case with big projects with poor code being rejected or
rewritten before being accepted. Keeping a house clean is easier and
less chaotic than cleaning a dirty house.

sufficiently varied in operation and purpose, you could at best have
guidelines for documentation. These are out there, and are being used.

gcc'. If there is an option there, its because it is needed.

always give warnings. Their relationship is virtually non-existent. I
say again, warnings don't always mean bad code.

or not is inconsequential. Thats the beauty of GNU free software. If
somebody finds a bug or wants a new feature then they can and will add
it for themselves. The baby never dies unless nobody uses it, in which
case, who cares?

to do! Believe it or not, they have lives that need living too. They
only take time to write free software for the reasons given above and
the freedom it gives programmers in general.

more pay than their day jobs, and at around $100/hr the reward would
have to be astronomical.

GNOME's Bounty Hunt works because these are features that people want.
If you get paid for providing them then "whoo-hoo" but thats not why you
do them. Heck, some people even decline the winnings and put it back in
the fund!


I agree that graphical applications are bigger than text-only
applications. This is simply due to the sheer complexity of displaying
graphics, not because of poor/unnecessary code.

Now that harddisks are so cheap, there's no valid reason to spend vast
quantities of time for the sole purpose of making applications smaller.
Its time better spent squashing bugs.

things. If you're really that concerned about them, just keep an eye on
the open-source security pages - the fixes are usually out only
hours/minutes of the problem being discovered.

know it sounds cliched but not if you know the facts: www.gnu.org

keeps on showing.

people to read it.

--
Ben M.

----------------
What are Software Patents for?
To protect the small enterprise from bigger companies.

What do Software Patents do?
In its current form, they protect only companies with
big legal departments as they:
a.) Patent everything no matter how general
b.) Sue everybody. Even if the patent can be argued
invalid, small companies can ill-afford the
typical $500k cost of a law-suit (not to mention
years of harassment).

Don't let them take away your right to program
whatever you like. Make a stand on Software Patents
before its too late.

Read about the ongoing battle at http://swpat.ffii.org/
----------------

Centuries ago, Nostradamus foresaw when Ben Measures <saint_abroadremove@removehotmail.com> would write:
In the case of the Linux kernel, there are two interesting effects
that have to be thrown in:

1. The kernel programmers have been known to examine the assembly
language generated by GCC, and to write code to produce the
desired effect.

2. The GCC team have been dueling with this somewhat, making the
compiler conform to _their interpretation_ of ANSI, ISO, and IEEE
standards. Which are not necessarily totally conformant with the
Linux kernel folks' understandings of those standards.

Keep in mind that there is room for interpretation of the C standards;
that there is not perfect agreement does _NOT_ establish that either
"camp" is necessarily wrong.
--
let name="cbbrowne" and tld="cbbrowne.com" in String.concat "@" [name;tld];;
http://www.ntlug.org/~cbbrowne/linuxdistributions.html
<a href="http://www.netizen.com.au/">thorfinn@netizen.com.au</a>
Millihelen, adj:
The amount of beauty required to launch one ship.

Christopher Browne wrote:
ROFL! Dunno why but I find that hilarious!

--
Ben M.

----------------
What are Software Patents for?
To protect the small enterprise from bigger companies.

What do Software Patents do?
In its current form, they protect only companies with
big legal departments as they:
a.) Patent everything no matter how general
b.) Sue everybody. Even if the patent can be argued
invalid, small companies can ill-afford the
typical $500k cost of a law-suit (not to mention
years of harassment).

Don't let them take away your right to program
whatever you like. Make a stand on Software Patents
before its too late.

Read about the ongoing battle at http://swpat.ffii.org/
----------------

In article <oyHPb.390$4t2.79@news-binary.blueyonder.co.uk>,
Ben Measures <saint_abroadremove@removehotmail.com> wrote:

Occasional warnings can be understood as anomalies. But if the screen
is full of them, as the OP said, this suggests sloppy coding. Even if
most of the warnings are benign, it's easy for the problematic ones to
get missed due to the volume. Also, if code generates a warning,
there's usually a simple modification that will generate equivalent code
but suppress the warning.

For instance, some compilers warn about code like:

if (<var> = <expression>) ...

on the assumption that this is a common typo for:

if (<var> == <expression>) ...

Wrapping the assignment in an extra set of parentheses will shut the
compiler up, with absolutely no effect on the generated code.

Many programming organizations have standards that require code to
compile with no warnings, and it's usually possible to achieve this (if
a warning really can't be worked around, they may allow a supervisor or
senior programmer to allow the exception).

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

On Thu, 22 Jan 2004 05:15:05 GMT, Barry Margolin <barmar@alum.mit.edu>
wrote:


a) demanded a comment per line of code
b) demanded flow charts for all functionality.

The former led to one or two sarcastic comments that the customer
picked up on and took exception ( ho ho ) to, and the latter much more
than doubled the length of the project.

Just because somebody requires it, doesn't make it worthwhile!

Steve

In article <hqnu00d3tutt87k080f5cepfc85kopl9ii@4ax.com>,
Steve Holdoway <steve@itemfront.ltd.uk> wrote:

Nor does it automatically make it worthless, either. Some programming
standards have a reasonable basis.

Warnings usually indicate that there's something wrong, or at least
suspicious. Even if you're sure they're benign, consider the plight of
the next developer to work on the code -- he'll have to go through all
the warnings, trying to figure out which can be ignored and which must
be resolved. The alternative is to blindly ignore all the warnings, in
which case you have a "boy who cried 'wolf'" situation -- inevitably a
warning that should be heeded will come out, and it will be ignored.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Barry Margolin wrote:
In most cases you can get rid of a warning with just a
minor code cleanup. There are of course cases, where a
warning generated for perfectly good code cannot
easilly be surpressed. For example warning about unused
function arguments is reasonable, if the argument
really isn't necesarry, it shouldn't be there at all.
In that case you could remove the argument from the
function and all callers. Of course there are exceptions.
It might be that the argument is required because of the
API being used in which case you can't simply get rid of
the warning.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
/* Would you like fries with that? */

In article <400F7448.E48C741E@daimi.au.dk>,
Kasper Dupont <kasperd@daimi.au.dk> wrote:

This is all correct. But as I said earlier, these should generally be
infrequent. If the screen is full of warnings, it's unlikely that all
of them are the ones that you can't easily suppress. 1-5 warnings per
program is probably not a big deal, but if there are dozens of them you
should do something about it.

Since we're talking about open source software, it's likely that other
people will be compiling your code when they install it. Lots of
warnings can have an impact on your reputation. And even if you don't
care about that, I expect that many of those users will send bug reports
asking whether the warnings are OK, and you'll have to deal with them.
So taking a little time to get rid of the warnings during development
can have some direct payoff later.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Barry Margolin <barmar@alum.mit.edu> writes:


It's unclear that the extra parenthesis are a good feature;
just like:

if (NULL == var)

is really very bad style (wonder when that pesky NULL
value changes)


What is wrong with writing:

if ((<var> = <expression>) != 0)

instead of:


if (<var> = <expression>)
or
if ((<var> = <expression>))

Casper

In article <400f8d4d$0$326$e4fe514c@news.xs4all.nl>,
Casper H.S. Dik <Casper.Dik@Sun.COM> wrote:

Let's not go off on a tangent of specific syntactic changes. Suffice it
to say that in most cases, all it takes is a slight revision to shut up
a warning. And in this way, developers can make the code compile
relatively cleanly. If there are a handful of warnings they can't get
rid of, these can be documented so that users and future developers
won't be caught off guard by them.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Kasper Dupont <kasperd@daimi.au.dk> writes:

(void) unused;

--
Måns Rullgård
mru@kth.se

Barry Margolin <barmar@alum.mit.edu> writes:

Yes, *if* there are lots of warnings. As a matter of fact, Linux
2.6.1 compiles without any warnings at all on one of my machines, and
maybe two or three warnings on another. Has the OP mistaken the
"gcc ..." lines for warnings?

--
Måns Rullgård
mru@kth.se

Barry Margolin wrote:
I agree with that. I have always told my students,
that I wanted their hand-ins to compile without
warnings. Of course I made a few exceptions.

Dunno. I think most end users will not worry about
the warnings if the code apears to work. And those
who really care about them will probably look in the
code themselves before contacting the author.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
/* Would you like fries with that? */

Måns Rullgård wrote:
That actually works.

int main(int argc, char ** argv)
{
(void) argv;
return argc;
}

--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
/* Would you like fries with that? */

Kasper Dupont <kasperd@daimi.au.dk>,
In a message on Thu, 22 Jan 2004 12:21:08 +0100, wrote :

KD> Måns Rullgård wrote:
KD> >
KD> > (void) unused;
KD>
KD> That actually works.
KD>
KD> int main(int argc, char ** argv)
KD> {
KD> (void) argv;
KD> return argc;
KD> }

I have lines like

static char rcsid[] = "$Id: Character.cc,v 1.3 2003/02/15 15:42:59 heller Exp $";

in many of my source files. The rcsid is never actually used in the
code. The compiler always issues a warning about rcsid being defined,
but never used. *I* know that these warning are ignorable. I could
comment out or remove these lines (to remove the warning), but that
would defeat the whole point of the line. What this code does is store
the ident string in the object file, where it can be located at some
later time with the ident program.

I don't believe that there is a 'hack' to suppress the warnings for
this sort of line. With enough source files, one can easily fill up a
screen with warnings for lines like this.

KD>
KD> --
KD> Kasper Dupont -- der bruger for meget tid paa usenet.
KD> For sending spam use mailto:aaarep@daimi.au.dk
KD> /* Would you like fries with that? */
KD>

\/
Robert Heller ||InterNet: heller@cs.umass.edu
http://vis-www.cs.umass.edu/~heller || heller@deepsoft.com
http://www.deepsoft.com /\FidoNet: 1:321/153

I code al the time like this, and nobody untill now was ever able telling me
why this was bad.
It is just as fast, just as clear but gives a compiler-error in case of a
typo.

But if you are the first to give me a good reasdon, I'll quit doing that.
:-)

It's slower ...
It affects the value of <var>

Armin

Barry Margolin wrote:
Ages ago, when running an old C compiler for the PDP-11/45 (the latest
at the time), we had a utility named "lint" that checked all kinds of
things. When I first discovered lint (soon after it came out), I would
get all kinds of advisory messages because of stuff like:


long int Numerator;
unsigned int Denominator;
int Remainder;
long int Quotient;

Quotient = Numerator / Denominator;
Remainder = Numerator % Denominator;


It would complain that the assignment to Remainder was risky.
Well, in general, it would be, but since Denominator was provably less
than a few hundred, this was never a problem. A suitable type cast fixed
the advisory message from lint. Asking for supervisor approval would not
have been a good idea because the construct appeared all over the place
and in those days, it did not make sense to write a function for the
remaindering and get that approved for efficiency reasons.

--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ Registered Machine 73926.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 8:30am up 15 days, 19:56, 6 users, load average: 2.18, 2.16, 2.10

Steve Holdoway <steve@itemfront.ltd.uk> wrote in
news:67ut00hjvt277bfcb7hnj8uag0u7di531b@4ax.com:

If the code that is to be cleaned up is done in a weeks time, ($100 for
discussion sake) is a lot of money in one week. They can move on to
other projects with similar rewards. It adds up. The developers can
clean up the code and make a living or have it as a secondary job.

Code Documentation, is for the longevity of the application. Someone
asked, why document each line of the code. When the open source
developer disappears with his new found girlfriend or boyfriend, there
should be someone to carry on the torch. Atleast each function should be
documented about the inputs, outputs and functionality.

The people who have contributed money to a project fund get to vote on
who contributed most to the project. The money is paid thru PayPal or
something like that. If the money has to be divided between different
coders, it is the contributers choice to do so.

We can already rate the applications at sourceforge.net. Why not rate
the developers and reward them accordingly?

The above article's theme brings us closer to getting secure systems and
secure applications. The developers have to be rewarded in some form or
the other. It is a fair thing to do.

BT