help / color / mirror / Atom feed
From: Ingo Schwarze <>
To: Baptiste Daroussin <>
Subject: Re: Allow gzipped .so and search .so in manpath
Date: Wed, 26 Nov 2014 21:10:33 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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.

 To unsubscribe send an email to

  reply	other threads:[~2014-11-26 20:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-24 14:36 Baptiste Daroussin
2014-11-26 20:10 ` Ingo Schwarze [this message]
2014-11-26 20:24   ` Baptiste Daroussin
2014-11-27  0:12     ` Ingo Schwarze
2014-11-27  2:03       ` Ingo Schwarze
2014-11-29 17:54       ` Baptiste Daroussin
2014-11-29 18:14         ` Ingo Schwarze

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).