From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from b-painless.mh.aa.net.uk ([81.187.30.52]) by ewsd; Wed Dec 19 03:16:53 EST 2018
Received: from 132.198.187.81.in-addr.arpa ([81.187.198.132] helo=quintile.net)
	by b-painless.mh.aa.net.uk with esmtp (Exim 4.89)
	(envelope-from <steve@quintile.net>)
	id 1gZX1u-0005zr-AF
	for 9front@9front.org; Wed, 19 Dec 2018 08:16:34 +0000
Received: from [10.243.143.117] ([185.69.145.253]) by quintile.net; Wed Dec 19 08:16:32 GMT 2018
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Steve Simon <steve@quintile.net>
Mime-Version: 1.0 (1.0)
Date: Wed, 19 Dec 2018 07:44:52 +0000
Subject: Re: Reading/understanding OS code (WAS: Re: [9front] !#&%&^#*@ RIO!!!)
Message-Id: <3740DDA2-8DEF-4B3F-9BE2-B4027B81E353@quintile.net>
References: <26B6FB24FAC120B8B424D0C3246CF039@felloff.net> <1544707691.1511402.1608097856.46B20629@webmail.messagingengine.com> <86sgyu311s.fsf_-_@cmarib.ramside> <alpine.LNX.2.00.1812190033320.1142@phi>
In-Reply-To: <alpine.LNX.2.00.1812190033320.1142@phi>
To: 9front@9front.org
X-Mailer: iPhone Mail (16B92)
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: hypervisor singleton-scale rich-client-oriented locator 


i can inly disagree. find plan9 code very, very clear and easy to read.

bstj == bell labs technical journal.

-Steve


On 18 Dec 2018, at 11:41 pm, Julius Schmidt <aiju@phicode.de> wrote:

>> That's why I gave up on using Plan 9 as a production operating system,
>> too.  Because Plan 9 is a free/open source operating system, in theory,
>> one should be able to read the code, verify its corectness, make fixes,
>> add enhancements, etc.  But on Plan 9, the whole system (kernel,
>> libraries, and application code) is written in old-style C, like UNIX.
>> It uses lots of variables with inscrutable names like "n", "p", "c", and
>> "d" and sports few, if any, comments.  I just got tired of trying to
>> keep track of which variables refer to what, and of deciphering what a
>> particular loop of code is trying to do.  Just what does "**p" mean,
>> anyway?  Another difficulty which Plan 9 code shares with UNIX is
>> keeping track of who owns which data structures in memory.  Who's
>> calling malloc(), and who (if anyone) is responsible for free()ing that
>> memory?  Like on UNIX, the Plan 9 manual pages are often silent on this,
>> and the source code usually doesn't document memory ownership, either.
>> The Plan 9 man pages use lots of Plan 9 jargon, so they're difficult to
>> understand unless you already know how the system works.  And, because
>> Plan 9 source code uses so many external functions, it is often tough to
>> find the relevant code.  When I started segfaulting applications and
>> seeing strange forms of corruption, I began looking at the code, and
>> realized how hard it is to read, debug, fix, enhance, or even verify.
>> Alas, code which can't be verified isn't reliable, and code which isn't
>> reliable isn't secure.
> 
> The funny thing is, I always found Plan 9 source to be remarkably clear
> compared to what other code I've seen.
> Things are generally clear enough on the macro-level that you can figure
> out what's going on the micro-level without too much trouble.
> 
> I wouldn't mind some more comments, particularly on assumptions, but I'm
> also bad at writing comments....