Steve Litt <slitt@???> writes:
> On Wed, 19 Aug 2015 18:25:45 +0100
> Rainer Weikusat <rainerweikusat@???> wrote:
>> Edward Bartolo <edbarx@???> writes:
>> > I am not assuming anything and understand the risks of buffer
>> > overflows. The first step I am taking is to make the code function.
>> > The second step is further debug it until it behaves properly and
>> > the third step is to correct any potential security issues.
>>
>> Realistically, the first step is 'make the code function', the second
>> step is 'graduate from university based on your thesis' and the 3rd
>> was called 'heartbleed', IOW, that's not going to happen in this way.
>> If you're doing string processing in C, try to do it correctly from
>> the start. That's much easier than retrofitting proper length/ size
>> handling onto some working code.
>
> LOL, hey guys, cut Edward some slack. He whipped this up in one day,
> when the rest of us, especially I, were sitting on our hands *with
> respect to a Wifi tool*.

I was commenting on the code and the methodology and not on him: As I
tried to demonstrate with the example I posted, it's not really
difficult to get it right from the start.

[...]

> In The Cathedral and the Bizaar, Eric Raymond says the following:
>
> ==================================================================
> When you start community-building, what you need to be able to present
> is a plausible promise. Your program doesn't have to work particularly
> well. It can be crude, buggy, incomplete and poorly documented. What it
> must not fail to do is (a) run, and (b) convince potential
> co-developers that it can be evolved into something really neat in the
> forseeable future.
> ==================================================================

In "The Cathedral of the Bizarre" (love this typo), it usually works
like this:

1. The code is buggy (for a certain definition of buggy) because whoever
originally wrote it couldn't be bothered to deal with the
issue. Because of this, should you be forced to fix it, don't bother
sharing the fix with the author: If he had cared about that, you
wouldn't have had to fix it and, and since he doesn't, he (at best)
won't care about you fix, anyway.

2. The code lacks features because none of the people who control it
were interested in them. In case you add some, don't bother trying to
share you changes: The people who control the code won't exactly be
happy when others suddenly try to exercise some control, too and
since they don't need the feature, they (at best) won't care. Should
someone sufficiently important need it in future, they'll reimplement
it.

Things may have worked differently in the early days of Linux (the
project) but that's because Linus Torvalds is an outstanding project
manager (among other things) but since Linux turned into a billion
dollar business, it stopped working in this way a long time ago.