From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailout.scc.kit.edu (mailout.scc.kit.edu [129.13.185.202]); by fantadrom.bsd.lv (OpenSMTPD) with ESMTP id a9c00e6a; for ; Wed, 26 Nov 2014 15:10:35 -0500 (EST) Received: from hekate.usta.de (asta-nat.asta.uni-karlsruhe.de [172.22.63.82]) by scc-mailout-02.scc.kit.edu with esmtp (Exim 4.72 #1) id 1Xtiv4-0006E5-2d; Wed, 26 Nov 2014 21:10:34 +0100 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.77) (envelope-from ) id 1Xtiv3-0002kf-Vx; Wed, 26 Nov 2014 21:10:33 +0100 Received: from iris.usta.de ([172.24.96.5] helo=usta.de) by donnerwolke.usta.de with esmtp (Exim 4.72) (envelope-from ) id 1Xtiv3-00066f-U0; Wed, 26 Nov 2014 21:10:33 +0100 Received: from schwarze by usta.de with local (Exim 4.77) (envelope-from ) id 1Xtiv3-0001LB-GK; Wed, 26 Nov 2014 21:10:33 +0100 Date: Wed, 26 Nov 2014 21:10:33 +0100 From: Ingo Schwarze To: Baptiste Daroussin Cc: tech@mdocml.bsd.lv Subject: Re: Allow gzipped .so and search .so in manpath Message-ID: <20141126201033.GG26411@iris.usta.de> References: <20141124143629.GB11567@ivaldir.etoilebsd.net> X-Mailinglist: mdocml-tech Reply-To: tech@mdocml.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141124143629.GB11567@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.21 (2010-09-15) Hi Baptiste, Baptiste Daroussin wrote on Mon, Nov 24, 2014 at 03:36:29PM +0100: > Here is a new patch that allows to open gzipped .so files > as well as looking inside mpath for the files requested. This is a terrible layering violation for three (!) reasons: 1. The mandoc toolbox consists of code in two major categories: a) code that is handling files irrespective of context b) code that is aware of file context / file systems While b) code is allowed to use a) code, the reverse is not true. The file read.c is part of the file handling code a), while manpath.h is part of the b) interface; so read.c cannot include manpath.h. It is true that the implementation of .so in roff.c (which is also part of a) slightly strains the "irrespective of context" paradigm by accessing another file. But at least it retrieves the file in exactly one well-defined place near the original file, and this strain is unavoidable if we want to support .so at all. Widening the gap by making read.c search for files along the path is neither acceptable nor needed. 2. As proposed, the patch is horribly inefficient. For some purposes, the function mparse_readfd() is called in inner loops, so it is not acceptable to do such expensive operations in there. Explained differently, we must not recalculate the manpath for each and every file we parse. Think about makewhatis(8), for example. Calculating the manpath belongs on the level of the main program, not into some inner loop in a library. 3. The patch utterly breaks the library hierarchy. The function mparse_readfd() is a libmandoc interface as documented in mandoc(3), while manpath.h is not. While manpath.c can (and does) use libmandoc, the reverse cannot happen. You see part of the havoc wrought in that you suddenly need manpath.o to link demandoc(1) even though that program does not use the manpath.h interface. I have to think about a better way to solve this. Maybe i should make mparse_readfd() use mparse_open() and extend mparse_open a bit to use file.gz if file is not found. Or something like that. It shouldn't take too long to figure out. > This allows zshall manpage which contains: .so man1/zshmodules.1 > to work with mandoc, tested on freebsd this .so find as expected > /usr/local/man/man1/zshmodules.1.gz The .so links are a bad idea in the first place, so it would be good to get rid of them completely. But admittedly, that's a separate matter. Yours, Ingo -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv