From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 20689 invoked from network); 29 Mar 2021 00:33:23 -0000 Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12) by inbox.vuxu.org with ESMTPUTF8; 29 Mar 2021 00:33:23 -0000 Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 22a0bf02 for ; Sun, 28 Mar 2021 19:33:17 -0500 (EST) Received: from scc-mailout-kit-02.scc.kit.edu (scc-mailout-kit-02.scc.kit.edu [129.13.231.82]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 359ea54e for ; Sun, 28 Mar 2021 19:33:16 -0500 (EST) Received: from hekate.asta.kit.edu ([141.3.145.153] helo=hekate.usta.de) by scc-mailout-kit-02.scc.kit.edu with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id 1lQfqE-0008DT-3E; Mon, 29 Mar 2021 02:33:14 +0200 Received: from donnerwolke.asta.kit.edu ([141.3.145.61] helo=donnerwolke.usta.de) by hekate.usta.de with esmtp (Exim 4.92.2) (envelope-from ) id 1lQfqC-0004Yg-Dr; Mon, 29 Mar 2021 02:33:12 +0200 Received: from login-1.asta.kit.edu ([141.3.145.72]) by donnerwolke.usta.de with esmtp (Exim 4.84_2) (envelope-from ) id 1lQfqC-0006ig-9I; Mon, 29 Mar 2021 02:33:12 +0200 Received: from schwarze by login-1.asta.kit.edu with local (Exim 4.92) (envelope-from ) id 1lQfqC-0004Ss-8V; Mon, 29 Mar 2021 02:33:12 +0200 Date: Mon, 29 Mar 2021 02:33:12 +0200 From: Ingo Schwarze To: "Anthony J. Bentley" Cc: tech@mandoc.bsd.lv Subject: Re: Improper formatting of table with T& Message-ID: References: <36636-1615006453.870094@W8oS.rk2z.-A1C> X-Mailinglist: mandoc-tech Reply-To: tech@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Hi, .. and by the way, after fixing the bug, i got worried there might be something i'm missing and there might be more problems hiding here because i wondered how it could possibly happen that before the patch i just sent to you, your (Anthony's) version of the test file (with the T&) exhibited the bug and my changed version (without the T& and the final layout line pulled up to the main layout block) worked. The *final* layout data structure ought to be just identical on both cases... So what was going on? The key is a few lines down in tbl_data.c, function tbl_data(), the top of which i patched. That function is actually used for parsing *any* data line, both those containing data and those containing only horizontal rulers. So consider what happens when the *ruler* is processed right after the title line of the table. Without my patch and with Anthony's version of the test file, sp->layout->next is NULL (because the T& has not yet been reached) so rp gets set to sp->layout (the layout line for the title), and then that gets used for initializing the span struture for the ruler, a few lines down in the switch statement. So the ruler gets associated with the *header* layout line and that doesn't change when the T& is later parsed. On the other hand, with my changed test file, the whole layout structure including the layout for data lines is already present when the ruler is parsed, so sp->layout->next is *not* NULL but the final layout line. Hence the ruler gets associated with the layout line intended for data. Of course, it doesn't matter at all which layout line is associated with a ruler, no layout is needed for rendering a ruler in the first place, so the difference doesn't matter for rendering the ruler itself. But then later, when parsing the first data line, the one for "days", the bug caused the meaningless layout pointer stored with the ruler to actually get used: the incorrect condition "sp->pos == TBL_SPAN_DATA" in the rp assignment line was false in this case, so whatever garbage pointer was there got used. That resulted in correct formatting (by chance) for my test file but blew up for Anthony's test file. I'm no longer convinced storing such meaningless pointers is a smart move, precisely because there is a risk something might use them down the line, causing erratic behaviour that is hard to disentangle. But at least i'm now confident i understand what was going on, and short of redesigning the invariants of struct tbl_span (which might improve rigour at the risk of causing regressions) i'm now confident my patch is correct. Yours, Ingo -- To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv