Re: [9fans] a bug in freopen

Re: [9fans] a bug in freopen

[presotto]

[-- Attachment #1: Type: text/plain, Size: 48 bytes --]

I'll fix it.  It is really crappy code.  Thanks.

[-- Attachment #2: Type: message/rfc822, Size: 1649 bytes --]

From: Saroj Mahapatra <saroj@optonline.net>
To: 9fans@cse.psu.edu
Subject: [9fans] a bug in freopen
Date: Mon, 5 Aug 2002 09:55:49 GMT
Message-ID: <6d3220b4.0208031631.2e8fd04e@posting.google.com>

There is a bug in freopen in that it checks mode[1] and mode[2]
without first checking if mode[0] is NULL char. So it may access
invalid memory location.

Thank you,
Saroj Mahapatra

Re: [9fans] a bug in freopen

[rob pike, esq.]

> It can be safely assumed that any really large software product
> contains bugs, period.  One might as well set up a procedure to
> deal with them..  As to security flaws, there are numerous
> contributing factors.

Are you sure?

-rob

Re: [9fans] a bug in freopen

[Douglas A. Gwyn]

"rob pike, esq." wrote:
> Are you sure?

Reasonably sure.

Re: [9fans] a bug in freopen

[Jim Choate]

On Fri, 9 Aug 2002, rob pike, esq. wrote:

> > It can be safely assumed that any really large software product
> > contains bugs, period.  One might as well set up a procedure to
> > deal with them..  As to security flaws, there are numerous
> > contributing factors.
>
> Are you sure?

I am, 2nd Law of Thermodynamics.

ps if you get ANKoS, check out p441.


 --
    ____________________________________________________________________

                  Conform and be dull......J. Frank Dobie

     ravage@ssz.com                                         www.ssz.com
     jchoate@open-forge.org                          www.open-forge.org

    --------------------------------------------------------------------

Re: [9fans] a bug in freopen

[presotto]

[-- Attachment #1: Type: text/plain, Size: 92 bytes --]

Rewritten and tested to my usual standards, i.e., it compiles
and my one test didn't abort.

[-- Attachment #2: Type: message/rfc822, Size: 3204 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 48 bytes --]

I'll fix it.  It is really crappy code.  Thanks.

[-- Attachment #2.1.2: Type: message/rfc822, Size: 1649 bytes --]

From: Saroj Mahapatra <saroj@optonline.net>
To: 9fans@cse.psu.edu
Subject: [9fans] a bug in freopen
Date: Mon, 5 Aug 2002 09:55:49 GMT
Message-ID: <6d3220b4.0208031631.2e8fd04e@posting.google.com>

There is a bug in freopen in that it checks mode[1] and mode[2]
without first checking if mode[0] is NULL char. So it may access
invalid memory location.

Thank you,
Saroj Mahapatra

Re: [9fans] a bug in freopen

[Jack Johnson]

presotto@plan9.bell-labs.com wrote:
> Rewritten and tested to my usual standards, i.e., it compiles
> and my one test didn't abort.

If only Microsoft would do that.

-Jack

Re: [9fans] a bug in freopen

[Douglas A. Gwyn]

Jack Johnson wrote:
> presotto@plan9.bell-labs.com wrote:
> > Rewritten and tested to my usual standards, i.e., it compiles
> > and my one test didn't abort.
> If only Microsoft would do that.

? In which direction do you think they err?  Too much testing or
too little?

Re: [9fans] a bug in freopen

[Jack Johnson]

Douglas A. Gwyn wrote:
> Jack Johnson wrote:
>>If only Microsoft would do that.
> ? In which direction do you think they err?  Too much testing or
> too little?

Sorry, Douglas (and everyone).  It was a bad pun run amok.

But, giving it some pre-coffee thought, they construct solutions to
perceived problems, which is a great business model.  I feel sometimes a
problem is not best solved by adding a new solution but by taking away
an old problem.  Maybe not the best way to run a software development
firm, but then again, I don't have that worry.

So, in that respect, I think they probably do more than adequate testing
  to ensure their product solves the problem they intended to fix (and
thus I damn their effort with faint praise).

When going through their recruitment process, I was told that (in the
group for which I was interviewing), the standard procedure was to spend
  24-36 months developing a new release, then releasing a service pack
roughly once every 6 months.  After 2-3 service packs, they'd determine
the new features they wanted in the next release, and go through the
cycle again. The service packs are released to fix bugs and add features
as requested by their largest vendors, and working down from there.

I was appalled at the idea that the working model was based on fixing
bugs after the release, that it was the expected norm, and that new
releases were not based on making the product qualitiatively (or hell,
quantitatively) better but firmly on adding new features, for which any
new bugs (that got through the testing cycle) would be worked out at a
later date.  Several times.

Now, I understand all software has bugs, and what a nightmare it must be
to manage 20,000 developers and n million lines of code, but if you want
an edict from Bill Gates, why not "Just One Service Pack"?  If the
standard procedure is to allow some bugs to be fixed post-production, it
seems no wonder that they've had certain difficulties with security.

----

Sorry for the rant.  The bad pun may have been better.

-Jack

P.S.
For the curious, I chose not to write VB script for a living, and my
checkbook resents it wholeheartedly.

Re: [9fans] a bug in freopen

[Douglas A. Gwyn]

Jack Johnson wrote:
> ... If the standard procedure is to allow some bugs to be fixed
> post-production, it seems no wonder that they've had certain
> difficulties with security.

It can be safely assumed that any really large software product
contains bugs, period.  One might as well set up a procedure to
deal with them..  As to security flaws, there are numerous
contributing factors.

[9fans] a bug in freopen

[Saroj Mahapatra]

There is a bug in freopen in that it checks mode[1] and mode[2]
without first checking if mode[0] is NULL char. So it may access
invalid memory location.

Thank you,
Saroj Mahapatra