'^\}$' is changed to a space character

'^\}$' is changed to a space character

[Bjarni Ingi Gislason]

  This is shown with (my version of test-groff)

test-groff -man -t -ww -b -z man7/vdso.7

troff: backtrace: file 'man7/vdso.7':146
troff:man7/vdso.7:146: warning: trailing space in the line
troff: backtrace: file 'man7/vdso.7':196
troff:man7/vdso.7:196: warning: trailing space in the line
troff: backtrace: file 'man7/vdso.7':225
troff:man7/vdso.7:225: warning: trailing space in the line
troff: backtrace: file 'man7/vdso.7':261
troff:man7/vdso.7:261: warning: trailing space in the line
troff: backtrace: file 'man7/vdso.7':279
troff:man7/vdso.7:279: warning: trailing space in the line
troff: backtrace: file 'man7/vdso.7':307
troff:man7/vdso.7:307: warning: trailing space in the line
troff: backtrace: file 'man7/vdso.7':369
troff:man7/vdso.7:369: warning: trailing space in the line
troff: backtrace: file 'man7/vdso.7':411
troff:man7/vdso.7:411: warning: trailing space in the line
troff: backtrace: file 'man7/vdso.7':451
troff:man7/vdso.7:451: warning: trailing space in the line
troff: backtrace: file 'man7/vdso.7':472
troff:man7/vdso.7:472: warning: trailing space in the line
troff: backtrace: file 'man7/vdso.7':490
troff:man7/vdso.7:490: warning: trailing space in the line
troff: backtrace: file 'man7/vdso.7':508
troff:man7/vdso.7:508: warning: trailing space in the line
troff: backtrace: file 'man7/vdso.7':526
troff:man7/vdso.7:526: warning: trailing space in the line
troff: backtrace: file 'man7/vdso.7':551
troff:man7/vdso.7:551: warning: trailing space in the line
troff: backtrace: file 'man7/vdso.7':570
troff:man7/vdso.7:570: warning: trailing space in the line

  This result in an empty line.

  Not all '^\}' lines are reported.

  grep -n -e '^\\\}$' shows all lines.

  Visible change is two empty lines after a table instead of a single line.

  A full stop should be used in front of '\}' to make the line a control
line.

  This also the case in some other files.

Re: '^\}$' is changed to a space character

[Alejandro Colomar]

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

Hi Bjarni,

On Tue, Sep 30, 2025 at 06:17:26PM +0000, Bjarni Ingi Gislason wrote:
>   This is shown with (my version of test-groff)
> 
> test-groff -man -t -ww -b -z man7/vdso.7
> 
> troff: backtrace: file 'man7/vdso.7':146
> troff:man7/vdso.7:146: warning: trailing space in the line
> troff: backtrace: file 'man7/vdso.7':196
> troff:man7/vdso.7:196: warning: trailing space in the line
> troff: backtrace: file 'man7/vdso.7':225
> troff:man7/vdso.7:225: warning: trailing space in the line
> troff: backtrace: file 'man7/vdso.7':261
> troff:man7/vdso.7:261: warning: trailing space in the line
> troff: backtrace: file 'man7/vdso.7':279
> troff:man7/vdso.7:279: warning: trailing space in the line
> troff: backtrace: file 'man7/vdso.7':307
> troff:man7/vdso.7:307: warning: trailing space in the line
> troff: backtrace: file 'man7/vdso.7':369
> troff:man7/vdso.7:369: warning: trailing space in the line
> troff: backtrace: file 'man7/vdso.7':411
> troff:man7/vdso.7:411: warning: trailing space in the line
> troff: backtrace: file 'man7/vdso.7':451
> troff:man7/vdso.7:451: warning: trailing space in the line
> troff: backtrace: file 'man7/vdso.7':472
> troff:man7/vdso.7:472: warning: trailing space in the line
> troff: backtrace: file 'man7/vdso.7':490
> troff:man7/vdso.7:490: warning: trailing space in the line
> troff: backtrace: file 'man7/vdso.7':508
> troff:man7/vdso.7:508: warning: trailing space in the line
> troff: backtrace: file 'man7/vdso.7':526
> troff:man7/vdso.7:526: warning: trailing space in the line
> troff: backtrace: file 'man7/vdso.7':551
> troff:man7/vdso.7:551: warning: trailing space in the line
> troff: backtrace: file 'man7/vdso.7':570
> troff:man7/vdso.7:570: warning: trailing space in the line
> 
>   This result in an empty line.
> 
>   Not all '^\}' lines are reported.
> 
>   grep -n -e '^\\\}$' shows all lines.
> 
>   Visible change is two empty lines after a table instead of a single line.
> 
>   A full stop should be used in front of '\}' to make the line a control
> line.
> 
>   This also the case in some other files.

Would you mind sending a patch?


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: '^\}$' is changed to a space character

[G. Branden Robinson]

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

At 2025-09-30T18:17:26+0000, Bjarni Ingi Gislason wrote:
>   This is shown with (my version of test-groff)

It's not just your version of "test-groff", a shell script built but not
installed by the groff build process, but your version/fork of groff as
a project.

In particular,

> test-groff -man -t -ww -b -z man7/vdso.7
> 
> troff: backtrace: file 'man7/vdso.7':146
> troff:man7/vdso.7:146: warning: trailing space in the line

...the foregoing is not a diagnostic message that GNU groff emits.

It's an unhelpful message in at least two respects.

* It doesn't identify a problem.  This sort of noun phrase is not a
  useful diagnostic.
* Because input lines and output lines are distinguishable in any
  program that fills, joins, breaks, or "folds" text, this diagnostic is
  furthermore unclear.

Moreover, trailing spaces on input lines are not _invalid_ in any *roff,
excepting possibly yours, which is private to you.

[...]
>   Visible change is two empty lines after a table instead of a single
>   line.

If that's the problem, then that is the defect you should report, not a
wall of (arguably spurious) warning diagnostics.

>   A full stop should be used in front of '\}' to make the line a
>   control line.

This counsel has nothing to do with the diagnostic you quoted
(repeatedly).

Here's the source:

$ sed -n '143,147p' man7/vdso.7
The exact name should not matter to any code, so do not hardcode it.
.if t \{\
.ft CW
\}
.TS

There are other valid (and economical) ways to employ the `\}` escape
sequence.  I've pointed this out to you before, recently.

https://lists.gnu.org/archive/html/bug-groff/2025-08/msg00177.html

So this is one possible fix:

 The exact name should not matter to any code, so do not hardcode it.
 .if t \{\
 .ft CW
-\}
+.\}
 .TS

...but so is this:

 The exact name should not matter to any code, so do not hardcode it.
 .if t \{\
-.ft CW
+.ft CW\}
 .TS

...and this:

 The exact name should not matter to any code, so do not hardcode it.
-.if t \{\
+.if t ft CW
-\}
 .TS

...and this:

diff --git a/man/man7/vdso.7 b/man/man7/vdso.7
index 0dc8bf6f2..88a561222 100644
--- a/man/man7/vdso.7
+++ b/man/man7/vdso.7
@@ -141,11 +141,9 @@ .SS vDSO names
 .BR ldd (1)
 output.
 The exact name should not matter to any code, so do not hardcode it.
-.if t \{\
-.ft CW
-\}
+.EX
 .TS
-l l.
+L L.
 user ABI       vDSO name
 _
 aarch64        linux\-vdso.so.1
@@ -162,10 +160,7 @@ .SS vDSO names
 x86-64 linux\-vdso.so.1
 x86/x32        linux\-vdso.so.1
 .TE
-.if t \{\
-.in
-.ft P
-\}
+.EE
 .SS strace(1), seccomp(2), and the vDSO
 When tracing system calls with
 .BR strace (1),

...but my recommendation is be the following.

diff --git a/man/man7/vdso.7 b/man/man7/vdso.7
index 0dc8bf6f2..750119996 100644
--- a/man/man7/vdso.7
+++ b/man/man7/vdso.7
@@ -141,11 +141,10 @@ .SS vDSO names
 .BR ldd (1)
 output.
 The exact name should not matter to any code, so do not hardcode it.
-.if t \{\
-.ft CW
-\}
+.P
 .TS
-l l.
+Lb Lb
+L  L .
 user ABI       vDSO name
 _
 aarch64        linux\-vdso.so.1
@@ -162,10 +161,6 @@ .SS vDSO names
 x86-64 linux\-vdso.so.1
 x86/x32        linux\-vdso.so.1
 .TE
-.if t \{\
-.in
-.ft P
-\}
 .SS strace(1), seccomp(2), and the vDSO
 When tracing system calls with
 .BR strace (1),

...and so on similarly for the rest of the tables in the document.

I can't imagine why anyone wanted them all in a constant-width face.

>   This also the case in some other files.

That claim doesn't help anyone.  If trailing spaces in "the line" don't
cause rendering problems in "other files", then there is no urgency to
change them, and, arguably, not even a defect in the first place.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: '^\}$' is changed to a space character

[G. Branden Robinson]

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

At 2025-09-30T14:40:06-0500, G. Branden Robinson wrote:
> ...and this:
> 
>  The exact name should not matter to any code, so do not hardcode it.
> -.if t \{\
> +.if t ft CW
> -\}
>  .TS

Whoops--in my annoyance with Bjarni, I managed to goof this instance of
hand-written (pseudo-?)diff.

Of course I meant:

-.if t \{\
-.ft CW
+.if t .ft CW
-\}
 .TS

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: '^\}$' is changed to a space character

[Bjarni Ingi Gislason]

  A patch is superfluous

sed -e '/^\\\}$/ {s/^/./}'

Re: '^\}$' is changed to a space character

[Alejandro Colomar]

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

Hi Bjarni.

On Tue, Sep 30, 2025 at 10:36:07PM +0000, Bjarni Ingi Gislason wrote:
>   A patch is superfluous
> 
> sed -e '/^\\\}$/ {s/^/./}'

This would also work; thanks!  After all, what I need is something I can
run to get the page changed.

On the other hand, I think I prefer Branden's approach, which entirely
eliminates the low-level roff(7) there.  What do you think?


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: '^\}$' is changed to a space character

[Bjarni Ingi Gislason]

On Wed, Oct 01, 2025 at 08:49:38AM +0200, Alejandro Colomar wrote:
> Hi Bjarni.
> 
> On Tue, Sep 30, 2025 at 10:36:07PM +0000, Bjarni Ingi Gislason wrote:
> >   A patch is superfluous
> > 
> > sed -e '/^\\\}$/ {s/^/./}'
> 
> This would also work; thanks!  After all, what I need is something I can
> run to get the page changed.
> 
> On the other hand, I think I prefer Branden's approach, which entirely
> eliminates the low-level roff(7) there.  What do you think?
> 
> 
  I did not get a copy of Branden's e-mail.

  I suggest to get your own knowledge of the troff language,

http://troff.org/54.pdf

so that you are not addicted to the opinions of others.

Re: '^\}$' is changed to a space character

[Alejandro Colomar]

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

Hi Branden,

You removed Bjarni from the recipient list.  I've bounced the emails to
Bjarni.


Have a lovely night!
Alex

On Tue, Sep 30, 2025 at 02:40:04PM -0500, G. Branden Robinson wrote:
> At 2025-09-30T18:17:26+0000, Bjarni Ingi Gislason wrote:
> >   This is shown with (my version of test-groff)
> 
> It's not just your version of "test-groff", a shell script built but not
> installed by the groff build process, but your version/fork of groff as
> a project.
> 
> In particular,
> 
> > test-groff -man -t -ww -b -z man7/vdso.7
> > 
> > troff: backtrace: file 'man7/vdso.7':146
> > troff:man7/vdso.7:146: warning: trailing space in the line
> 
> ...the foregoing is not a diagnostic message that GNU groff emits.
> 
> It's an unhelpful message in at least two respects.
> 
> * It doesn't identify a problem.  This sort of noun phrase is not a
>   useful diagnostic.
> * Because input lines and output lines are distinguishable in any
>   program that fills, joins, breaks, or "folds" text, this diagnostic is
>   furthermore unclear.
> 
> Moreover, trailing spaces on input lines are not _invalid_ in any *roff,
> excepting possibly yours, which is private to you.
> 
> [...]
> >   Visible change is two empty lines after a table instead of a single
> >   line.
> 
> If that's the problem, then that is the defect you should report, not a
> wall of (arguably spurious) warning diagnostics.
> 
> >   A full stop should be used in front of '\}' to make the line a
> >   control line.
> 
> This counsel has nothing to do with the diagnostic you quoted
> (repeatedly).
> 
> Here's the source:
> 
> $ sed -n '143,147p' man7/vdso.7
> The exact name should not matter to any code, so do not hardcode it.
> .if t \{\
> .ft CW
> \}
> .TS
> 
> There are other valid (and economical) ways to employ the `\}` escape
> sequence.  I've pointed this out to you before, recently.
> 
> https://lists.gnu.org/archive/html/bug-groff/2025-08/msg00177.html
> 
> So this is one possible fix:
> 
>  The exact name should not matter to any code, so do not hardcode it.
>  .if t \{\
>  .ft CW
> -\}
> +.\}
>  .TS
> 
> ...but so is this:
> 
>  The exact name should not matter to any code, so do not hardcode it.
>  .if t \{\
> -.ft CW
> +.ft CW\}
>  .TS
> 
> ...and this:
> 
>  The exact name should not matter to any code, so do not hardcode it.
> -.if t \{\
> +.if t ft CW
> -\}
>  .TS
> 
> ...and this:
> 
> diff --git a/man/man7/vdso.7 b/man/man7/vdso.7
> index 0dc8bf6f2..88a561222 100644
> --- a/man/man7/vdso.7
> +++ b/man/man7/vdso.7
> @@ -141,11 +141,9 @@ .SS vDSO names
>  .BR ldd (1)
>  output.
>  The exact name should not matter to any code, so do not hardcode it.
> -.if t \{\
> -.ft CW
> -\}
> +.EX
>  .TS
> -l l.
> +L L.
>  user ABI       vDSO name
>  _
>  aarch64        linux\-vdso.so.1
> @@ -162,10 +160,7 @@ .SS vDSO names
>  x86-64 linux\-vdso.so.1
>  x86/x32        linux\-vdso.so.1
>  .TE
> -.if t \{\
> -.in
> -.ft P
> -\}
> +.EE
>  .SS strace(1), seccomp(2), and the vDSO
>  When tracing system calls with
>  .BR strace (1),
> 
> ...but my recommendation is be the following.
> 
> diff --git a/man/man7/vdso.7 b/man/man7/vdso.7
> index 0dc8bf6f2..750119996 100644
> --- a/man/man7/vdso.7
> +++ b/man/man7/vdso.7
> @@ -141,11 +141,10 @@ .SS vDSO names
>  .BR ldd (1)
>  output.
>  The exact name should not matter to any code, so do not hardcode it.
> -.if t \{\
> -.ft CW
> -\}
> +.P
>  .TS
> -l l.
> +Lb Lb
> +L  L .
>  user ABI       vDSO name
>  _
>  aarch64        linux\-vdso.so.1
> @@ -162,10 +161,6 @@ .SS vDSO names
>  x86-64 linux\-vdso.so.1
>  x86/x32        linux\-vdso.so.1
>  .TE
> -.if t \{\
> -.in
> -.ft P
> -\}
>  .SS strace(1), seccomp(2), and the vDSO
>  When tracing system calls with
>  .BR strace (1),
> 
> ...and so on similarly for the rest of the tables in the document.
> 
> I can't imagine why anyone wanted them all in a constant-width face.
> 
> >   This also the case in some other files.
> 
> That claim doesn't help anyone.  If trailing spaces in "the line" don't
> cause rendering problems in "other files", then there is no urgency to
> change them, and, arguably, not even a defect in the first place.
> 
> Regards,
> Branden



-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: '^\}$' is changed to a space character

[Alejandro Colomar]

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

Hi Branden,

On Tue, Sep 30, 2025 at 02:40:04PM -0500, G. Branden Robinson wrote:
> ...but my recommendation is be the following.
> 
> diff --git a/man/man7/vdso.7 b/man/man7/vdso.7
> index 0dc8bf6f2..750119996 100644
> --- a/man/man7/vdso.7
> +++ b/man/man7/vdso.7
> @@ -141,11 +141,10 @@ .SS vDSO names
>  .BR ldd (1)
>  output.
>  The exact name should not matter to any code, so do not hardcode it.
> -.if t \{\
> -.ft CW
> -\}
> +.P
>  .TS
> -l l.
> +Lb Lb
> +L  L .o

For consistency with the rest of the project, I've used 'lB' instead of
'Lb'.

>  user ABI       vDSO name
>  _
>  aarch64        linux\-vdso.so.1
> @@ -162,10 +161,6 @@ .SS vDSO names
>  x86-64 linux\-vdso.so.1
>  x86/x32        linux\-vdso.so.1
>  .TE
> -.if t \{\
> -.in
> -.ft P
> -\}
>  .SS strace(1), seccomp(2), and the vDSO
>  When tracing system calls with
>  .BR strace (1),

I like this change.  I've applied this commit:

<https://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git/commit/?h=contrib&id=fa940b6d17791a166c793b74a50cd72926d14b50>

Here's the head(1) of it:

	$ git show | head -n40
	commit fa940b6d17791a166c793b74a50cd72926d14b50
	Author: Alejandro Colomar <alx@kernel.org>
	Date:   Sat Oct 4 10:48:02 2025 +0200

	    man/man7/vdso.7: ffix
	    
	    Reported-by: Bjarni Ingi Gislason <bjarniig@simnet.is>
	    Suggested-by: "G. Branden Robinson" <branden@debian.org>
	    Signed-off-by: Alejandro Colomar <alx@kernel.org>

	diff --git a/man/man7/vdso.7 b/man/man7/vdso.7
	index 0dc8bf6f2..8c8d00514 100644
	--- a/man/man7/vdso.7
	+++ b/man/man7/vdso.7
	@@ -141,11 +141,10 @@ .SS vDSO names
	 .BR ldd (1)
	 output.
	 The exact name should not matter to any code, so do not hardcode it.
	-.if t \{\
	-.ft CW
	-\}
	+.P
	 .TS
	-l l.
	+lB lB
	+l  l .
	 user ABI	vDSO name
	 _
	 aarch64	linux\-vdso.so.1
	@@ -162,10 +161,6 @@ .SS vDSO names
	 x86-64	linux\-vdso.so.1
	 x86/x32	linux\-vdso.so.1
	 .TE
	-.if t \{\
	-.in
	-.ft P
	-\}
	 .SS strace(1), seccomp(2), and the vDSO
	 When tracing system calls with
	 .BR strace (1),

BTW, in the PDF, the '.P' doesn't seem to be working.
<https://www.alejandro-colomar.es:80/share/dist/man-pages/git/HEAD/man-pages-HEAD.pdf#vdso.7>

I don't see the space before the tables.  Compare with the old PDF:
<https://mirrors.edge.kernel.org/pub/linux/docs/man-pages/book/man-pages-6.15.pdf#vdso.7>

> ...and so on similarly for the rest of the tables in the document.

The only other one I can see is syscalls(2).  That one is a bit weird,
so I'd like you to have a look at it and tell me what you'd do.


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: '^\}$' is changed to a space character

[G. Branden Robinson]

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

Hi Alex,

At 2025-10-04T11:16:06+0200, Alejandro Colomar wrote:
[snip]
> > -l l.
> > +Lb Lb
> > +L  L .o
> 
> For consistency with the rest of the project, I've used 'lB' instead
> of 'Lb'.

Okay.  That happens to be the precise opposite of my preference; I think
the column classifier is the more important property and column
modifier(s), if present at all, less important.  But tbl(1)'s matching
is case-insensitive, so it's purely a question of house style.

And consistency is king.  :)  Or co-king with "clarity"...

> I like this change.  I've applied this commit:
> 
> <https://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git/commit/?h=contrib&id=fa940b6d17791a166c793b74a50cd72926d14b50>

Looks good to me...but it _would_.  ;-)

> BTW, in the PDF, the '.P' doesn't seem to be working.

> <https://www.alejandro-colomar.es:80/share/dist/man-pages/git/HEAD/man-pages-HEAD.pdf#vdso.7>

Hmm, yes that does look wrong.  Plus, I see too much vertical space
_after_ the "ARM functions" table.

I'll get back to you on this.

> I don't see the space before the tables.  Compare with the old PDF:
> <https://mirrors.edge.kernel.org/pub/linux/docs/man-pages/book/man-pages-6.15.pdf#vdso.7>
> 
> > ...and so on similarly for the rest of the tables in the document.
> 
> The only other one I can see is syscalls(2).  That one is a bit weird,
> so I'd like you to have a look at it and tell me what you'd do.

By "in the document", I meant only the vdso(7) page itself.

I don't know if I have the spoons to tackle issues in syscalls(2) before
I follow up with you carrying my sed(1)-driven bucket of thunderbolts.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: '^\}$' is changed to a space character

[Alejandro Colomar]

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

Hi Branden,

On Sat, Oct 04, 2025 at 04:42:43AM -0500, G. Branden Robinson wrote:
> Hi Alex,
> 
> At 2025-10-04T11:16:06+0200, Alejandro Colomar wrote:
> [snip]
> > > -l l.
> > > +Lb Lb
> > > +L  L .o
> > 
> > For consistency with the rest of the project, I've used 'lB' instead
> > of 'Lb'.
> 
> Okay.  That happens to be the precise opposite of my preference; I think
> the column classifier is the more important property and column
> modifier(s), if present at all, less important.  But tbl(1)'s matching
> is case-insensitive, so it's purely a question of house style.

I like from lB that B is well-known for bold, but 'b' not so much.

> And consistency is king.  :)  Or co-king with "clarity"...
> 
> > I like this change.  I've applied this commit:
> > 
> > <https://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git/commit/?h=contrib&id=fa940b6d17791a166c793b74a50cd72926d14b50>
> 
> Looks good to me...but it _would_.  ;-)
> 
> > BTW, in the PDF, the '.P' doesn't seem to be working.
> 
> > <https://www.alejandro-colomar.es:80/share/dist/man-pages/git/HEAD/man-pages-HEAD.pdf#vdso.7>
> 
> Hmm, yes that does look wrong.  Plus, I see too much vertical space
> _after_ the "ARM functions" table.
> 
> I'll get back to you on this.

Okay.

> > I don't see the space before the tables.  Compare with the old PDF:
> > <https://mirrors.edge.kernel.org/pub/linux/docs/man-pages/book/man-pages-6.15.pdf#vdso.7>
> > 
> > > ...and so on similarly for the rest of the tables in the document.
> > 
> > The only other one I can see is syscalls(2).  That one is a bit weird,
> > so I'd like you to have a look at it and tell me what you'd do.
> 
> By "in the document", I meant only the vdso(7) page itself.

I somehow misread; it was quite clearly written.  :)

> I don't know if I have the spoons to tackle issues in syscalls(2) before
> I follow up with you carrying my sed(1)-driven bucket of thunderbolts.

:-)


Cheers,
Alex

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: '^\}$' is (not) changed to a space character

[G. Branden Robinson]

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

Hi Alex,

First I must correct the subject line.  '^\}$' is not "changed to a
space character".  I explain below.

At 2025-10-04T04:42:43-0500, G. Branden Robinson wrote:
> At 2025-10-04T11:16:06+0200, Alejandro Colomar wrote:
> > BTW, in the PDF, the '.P' doesn't seem to be working.
> 
> > <https://www.alejandro-colomar.es:80/share/dist/man-pages/git/HEAD/man-pages-HEAD.pdf#vdso.7>
> 
> Hmm, yes that does look wrong.  Plus, I see too much vertical space
> _after_ the "ARM functions" table.
> 
> I'll get back to you on this.

The problems are straightforward.  Here's the relevant source.

---snip---
.SS ARM functions
.\" See linux/arch/arm/vdso/vdso.lds.S
.\" Commit: 8512287a8165592466cb9cb347ba94892e9c56a5
The table below lists the symbols exported by the vDSO.
.if t \{\
.ft CW
\}
.TS
l l.
symbol	version
_
__vdso_gettimeofday	LINUX_2.6 (exported since Linux 4.1)
__vdso_clock_gettime	LINUX_2.6 (exported since Linux 4.1)
.TE
.if t \{\
.in
.ft P
\}
.P
.\" See linux/arch/arm/kernel/entry-armv.S
.\" See linux/Documentation/arm/kernel_user_helpers.rst
Additionally, the ARM port has a code page full of utility functions.
---end snip---

As Bjarni pointed out, you probably want a *roff control character
(typically `.`) before those closing brace escape sequences.  If the
branch of the conditional is taken, the closing brace sequence has no
effect itself on formatting, but the blank line that remains _does_,
just as with a `\"` comment.

https://www.gnu.org/software/groff/manual/groff.html.node/Comments.html

That explains the excessive vertical space after the table when
rendering to PDF.  But what about the missing vertical space _before_
it?  The same spurious blank line is there, too, when typesetting--why
doesn't it have effect?

man(7), like other macro packages, employs a formatter feature called
"no-space mode" in its sectioning macros.[1]  This means that attempts
to put vertical space on the output fail until at least one glyph (or
drawing primitive) is typeset.  Looking over groff_man(7), I don't see
that I've actually documented this--so, homework for me.  (This is the
reason that calling the `P`--or `LP` or `PP` macros-- immediately after
`SH` or `SS` has no visible effect.  `HP`, `IP`, and `TP` work normally
except for the inter-paragraph space they ordinarily apply.)

You _can_ disable no-space mode with the `rs` request.  Other approaches
would be to simply let the table abut the (sub)section heading, or
precede the table with an explanatory sentence.

Regards,
Branden

[1] Strictly, groff man(7) currently enables no-space mode in an
    internal macro named `an*break-paragraph`, which all of the
    sectioning and paragraphing macros call.  The consequence is that
    the following input:

    Foo.
    .PP
    .sp 3i
    Bar.

    ...does not put three inches of space between the paragraphs, but
    only the configured inter-paragraph spacing amount.

    The `TH` macro also (indirectly, via a trap macro that sets the page
    header) enters no-space mode after writing the page header.  These
    provisions are all to keep an inexpert man(7) document author from
    making a hash of things.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: '^\}$' is (not) changed to a space character

[Alejandro Colomar]

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

Hi Branden,

On Sun, Oct 05, 2025 at 08:48:12AM -0500, G. Branden Robinson wrote:
> Hi Alex,
> 
> First I must correct the subject line.  '^\}$' is not "changed to a
> space character".  I explain below.
> 
> At 2025-10-04T04:42:43-0500, G. Branden Robinson wrote:
> > At 2025-10-04T11:16:06+0200, Alejandro Colomar wrote:
> > > BTW, in the PDF, the '.P' doesn't seem to be working.
> > 

URL edited:

> > > <https://www.alejandro-colomar.es/share/dist/man-pages/git/HEAD/man-pages-HEAD.pdf#vdso.7>

Shit, I forgot to remove the port when pasting the URL.  Hopefully,
crawlers won't follow it and DDoS me again.  Otherwise I shall install
Anubis.

> > Hmm, yes that does look wrong.  Plus, I see too much vertical space
> > _after_ the "ARM functions" table.
> > 
> > I'll get back to you on this.
> 
> The problems are straightforward.  Here's the relevant source.
> 
> ---snip---
> .SS ARM functions
> .\" See linux/arch/arm/vdso/vdso.lds.S
> .\" Commit: 8512287a8165592466cb9cb347ba94892e9c56a5
> The table below lists the symbols exported by the vDSO.
> .if t \{\
> .ft CW
> \}
> .TS
> l l.
> symbol	version
> _
> __vdso_gettimeofday	LINUX_2.6 (exported since Linux 4.1)
> __vdso_clock_gettime	LINUX_2.6 (exported since Linux 4.1)
> .TE
> .if t \{\
> .in
> .ft P
> \}
> .P
> .\" See linux/arch/arm/kernel/entry-armv.S
> .\" See linux/Documentation/arm/kernel_user_helpers.rst
> Additionally, the ARM port has a code page full of utility functions.
> ---end snip---
> 
> As Bjarni pointed out, you probably want a *roff control character
> (typically `.`) before those closing brace escape sequences.  If the
> branch of the conditional is taken, the closing brace sequence has no
> effect itself on formatting, but the blank line that remains _does_,
> just as with a `\"` comment.

In that link I had already applied this commit:

	commit fa940b6d17791a166c793b74a50cd72926d14b50
	Author: Alejandro Colomar <alx@kernel.org>
	Date:   Sat Oct 4 10:48:02 2025 +0200

	    man/man7/vdso.7: ffix
	    
	    Reported-by: Bjarni Ingi Gislason <bjarniig@simnet.is>
	    Suggested-by: "G. Branden Robinson" <branden@debian.org>
	    Signed-off-by: Alejandro Colomar <alx@kernel.org>

	diff --git a/man/man7/vdso.7 b/man/man7/vdso.7
	index 0dc8bf6f2..8c8d00514 100644
	--- a/man/man7/vdso.7
	+++ b/man/man7/vdso.7
	@@ -141,11 +141,10 @@ .SS vDSO names
	 .BR ldd (1)
	 output.
	 The exact name should not matter to any code, so do not hardcode it.
	-.if t \{\
	-.ft CW
	-\}
	+.P
	 .TS
	-l l.
	+lB lB
	+l  l .
	 user ABI       vDSO name
	 _
	 aarch64        linux\-vdso.so.1
	@@ -162,10 +161,6 @@ .SS vDSO names
	 x86-64 linux\-vdso.so.1
	 x86/x32        linux\-vdso.so.1
	 .TE
	-.if t \{\
	-.in
	-.ft P
	-\}
	 .SS strace(1), seccomp(2), and the vDSO
	 When tracing system calls with
	 .BR strace (1),
	@@ ...
	...

So, I expect the explanation shouldn't hold anymore, right?  There are
no closing brace escape sequences anymore.

> https://www.gnu.org/software/groff/manual/groff.html.node/Comments.html
> 
> That explains the excessive vertical space after the table when
> rendering to PDF.  But what about the missing vertical space _before_
> it?  The same spurious blank line is there, too, when typesetting--why
> doesn't it have effect?
> 
> man(7), like other macro packages, employs a formatter feature called
> "no-space mode" in its sectioning macros.[1]  This means that attempts
> to put vertical space on the output fail until at least one glyph (or
> drawing primitive) is typeset.  Looking over groff_man(7), I don't see
> that I've actually documented this--so, homework for me.  (This is the
> reason that calling the `P`--or `LP` or `PP` macros-- immediately after
> `SH` or `SS` has no visible effect.  `HP`, `IP`, and `TP` work normally
> except for the inter-paragraph space they ordinarily apply.)
> 
> You _can_ disable no-space mode with the `rs` request.  Other approaches
> would be to simply let the table abut

Hmmm, new word for my vocabulary!  :D


Cheers,
Alex

> the (sub)section heading, or
> precede the table with an explanatory sentence.
> 
> Regards,
> Branden
> 
> [1] Strictly, groff man(7) currently enables no-space mode in an
>     internal macro named `an*break-paragraph`, which all of the
>     sectioning and paragraphing macros call.  The consequence is that
>     the following input:
> 
>     Foo.
>     .PP
>     .sp 3i
>     Bar.
> 
>     ...does not put three inches of space between the paragraphs, but
>     only the configured inter-paragraph spacing amount.
> 
>     The `TH` macro also (indirectly, via a trap macro that sets the page
>     header) enters no-space mode after writing the page header.  These
>     provisions are all to keep an inexpert man(7) document author from
>     making a hash of things.



-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: '^\}$' is (not) changed to a space character

[G. Branden Robinson]

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

Hi Alex,

At 2025-10-05T20:47:02+0200, Alejandro Colomar wrote:
> URL edited:
> 
> > > > <https://www.alejandro-colomar.es/share/dist/man-pages/git/HEAD/man-pages-HEAD.pdf#vdso.7>
> 
> Shit, I forgot to remove the port when pasting the URL.  Hopefully,
> crawlers won't follow it and DDoS me again.  Otherwise I shall install
> Anubis.

As an obscure ficitious personage named Eadric of Deorham once said,
"they'll always find a way".

> > As Bjarni pointed out, you probably want a *roff control character
> > (typically `.`) before those closing brace escape sequences.  If the
> > branch of the conditional is taken, the closing brace sequence has
> > no effect itself on formatting, but the blank line that remains
> > _does_, just as with a `\"` comment.
> 
> In that link I had already applied this commit:
> 
[...]
> 	-.if t \{\
> 	-.ft CW
> 	-\}
> 	+.P
[...]

> So, I expect the explanation shouldn't hold anymore, right?  There are
> no closing brace escape sequences anymore.

Right, but the excess space in the document should not still be present,
either.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: '^\}$' is (not) changed to a space character

[Alejandro Colomar]

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

Hi Branden,

On Mon, Oct 06, 2025 at 03:51:49AM -0500, G. Branden Robinson wrote:
> > 	-.if t \{\
> > 	-.ft CW
> > 	-\}
> > 	+.P
> [...]
> 
> > So, I expect the explanation shouldn't hold anymore, right?  There are
> > no closing brace escape sequences anymore.
> 
> Right, but the excess space in the document should not still be present,
> either.

Hmmm, it's weird.  If I produce the PDF in my computer, the space is
now correct.  However, the PDF book served on my website still has the
wrong space.  I know it has the correct source code, because it doesn't
use CW anymore.

The only difference I can see is the groff(1) version.  In my computer,
I have

	GNU groff version 1.23.0.2695-49927

but on my server I have

	GNU groff version 1.23.0.1254-19a18

But I also tested 1.23.0, and it does the right thing.
Maybe the version on my server has a temporary bug that appeared after
1.23.0 and was fixed before 1.23.0.2695-49927.

I tried building groff from git HEAD to see if that fixed the issues in
my server.  However, it seems groff doesn't build at the moment:

	$ make 
	make  all-recursive
	make[1]: Entering directory '/srv/alx/src/gnu/groff/master'
	make[2]: Entering directory '/srv/alx/src/gnu/groff/master'
	  CXX      src/roff/troff/div.o
	In file included from src/roff/troff/div.cpp:29:
	src/roff/troff/hvunits.h: In member function ‘units vunits::to_units()’:
	src/roff/troff/hvunits.h:91:7: error: ‘ckd_mul’ was not declared in this scope
	   91 |   if (ckd_mul(&r, n, vresolution))
	      |       ^~~~~~~
	src/roff/troff/hvunits.h: In function ‘vunits operator+(const vunits&, const vunits&)’:
	src/roff/troff/hvunits.h:105:7: error: ‘ckd_add’ was not declared in this scope
	  105 |   if (ckd_add(&r.n, r.n, y.n))
	      |       ^~~~~~~
	src/roff/troff/hvunits.h: In function ‘vunits operator-(const vunits&, const vunits&)’:
	src/roff/troff/hvunits.h:114:7: error: ‘ckd_sub’ was not declared in this scope
	  114 |   if (ckd_sub(&r.n, r.n, y.n))
	      |       ^~~~~~~
	src/roff/troff/hvunits.h: In function ‘vunits operator-(const vunits&)’:
	src/roff/troff/hvunits.h:123:7: error: ‘ckd_mul’ was not declared in this scope
	  123 |   if (ckd_mul(&r.n, x.n, -1))
	      |       ^~~~~~~
	src/roff/troff/hvunits.h: In function ‘vunits operator*(const vunits&, int)’:
	src/roff/troff/hvunits.h:145:7: error: ‘ckd_mul’ was not declared in this scope
	  145 |   if (ckd_mul(&r.n, x.n, n))
	      |       ^~~~~~~
	src/roff/troff/hvunits.h: In function ‘vunits operator*(int, const vunits&)’:
	src/roff/troff/hvunits.h:154:7: error: ‘ckd_mul’ was not declared in this scope
	  154 |   if (ckd_mul(&r.n, n, x.n))
	      |       ^~~~~~~
	src/roff/troff/hvunits.h: In member function ‘units hunits::to_units()’:
	src/roff/troff/hvunits.h:208:7: error: ‘ckd_mul’ was not declared in this scope
	  208 |   if (ckd_mul(&r, n, hresolution))
	      |       ^~~~~~~
	src/roff/troff/hvunits.h: In function ‘hunits operator+(const hunits&, const hunits&)’:
	src/roff/troff/hvunits.h:222:7: error: ‘ckd_add’ was not declared in this scope
	  222 |   if (ckd_add(&r.n, r.n, y.n))
	      |       ^~~~~~~
	src/roff/troff/hvunits.h: In function ‘hunits operator-(const hunits&, const hunits&)’:
	src/roff/troff/hvunits.h:231:7: error: ‘ckd_sub’ was not declared in this scope
	  231 |   if (ckd_sub(&r.n, r.n, y.n))
	      |       ^~~~~~~
	src/roff/troff/hvunits.h: In function ‘hunits operator-(const hunits&)’:
	src/roff/troff/hvunits.h:241:7: error: ‘ckd_mul’ was not declared in this scope
	  241 |   if (ckd_mul(&r.n, x.n, -1))
	      |       ^~~~~~~
	src/roff/troff/hvunits.h: In function ‘hunits operator*(const hunits&, int)’:
	src/roff/troff/hvunits.h:263:7: error: ‘ckd_mul’ was not declared in this scope
	  263 |   if (ckd_mul(&r.n, x.n, n))
	      |       ^~~~~~~
	src/roff/troff/hvunits.h: In function ‘hunits operator*(int, const hunits&)’:
	src/roff/troff/hvunits.h:272:7: error: ‘ckd_mul’ was not declared in this scope
	  272 |   if (ckd_mul(&r.n, x.n, n))
	      |       ^~~~~~~
	src/roff/troff/div.cpp: In member function ‘virtual void macro_diversion::output(node*, bool, vunits, vunits, hunits)’:
	src/roff/troff/div.cpp:325:7: error: ‘ckd_add’ was not declared in this scope
	  325 |   if (ckd_add(&new_vpos, vpos, lineht))
	      |       ^~~~~~~
	make[2]: *** [Makefile:9395: src/roff/troff/div.o] Error 1
	make[2]: Leaving directory '/srv/alx/src/gnu/groff/master'
	make[1]: *** [Makefile:11776: all-recursive] Error 1
	make[1]: Leaving directory '/srv/alx/src/gnu/groff/master'
	make: *** [Makefile:6977: all] Error 2

Did you forget some #include?


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

groff build problem involving "ckd_mul" and "ckd_add"

[G. Branden Robinson]

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

[looping in groff@gnu list]

[was: '^\}$' is (not) changed to a space character]

Hi Alex,

At 2025-10-06T12:25:23+0200, Alejandro Colomar wrote:
> On Mon, Oct 06, 2025 at 03:51:49AM -0500, G. Branden Robinson wrote:
> > Right, but the excess space in the document should not still be
> > present, either.
> 
> Hmmm, it's weird.  If I produce the PDF in my computer, the space is
> now correct.  However, the PDF book served on my website still has the
> wrong space.  I know it has the correct source code, because it
> doesn't use CW anymore.
> 
> The only difference I can see is the groff(1) version.  In my computer,
> I have
> 
> 	GNU groff version 1.23.0.2695-49927
> 
> but on my server I have
> 
> 	GNU groff version 1.23.0.1254-19a18
> 
> But I also tested 1.23.0, and it does the right thing.  Maybe the
> version on my server has a temporary bug that appeared after 1.23.0
> and was fixed before 1.23.0.2695-49927.

That could explain it.  I find bugs I introduced myself all the time.
(Such discoveries often drive new regression test scripts.) This one
doesn't ring a bell, but that doesn't mean much.

> I tried building groff from git HEAD to see if that fixed the issues
> in my server.  However, it seems groff doesn't build at the moment:
> 
> 	$ make 
> 	make  all-recursive
> 	make[1]: Entering directory '/srv/alx/src/gnu/groff/master'
> 	make[2]: Entering directory '/srv/alx/src/gnu/groff/master'
> 	  CXX      src/roff/troff/div.o
> 	In file included from src/roff/troff/div.cpp:29:
> 	src/roff/troff/hvunits.h: In member function ‘units vunits::to_units()’:
> 	src/roff/troff/hvunits.h:91:7: error: ‘ckd_mul’ was not declared in this scope
> 	   91 |   if (ckd_mul(&r, n, vresolution))
> 	      |       ^~~~~~~
> 	src/roff/troff/hvunits.h: In function ‘vunits operator+(const vunits&, const vunits&)’:
> 	src/roff/troff/hvunits.h:105:7: error: ‘ckd_add’ was not declared in this scope
> 	  105 |   if (ckd_add(&r.n, r.n, y.n))
> 	      |       ^~~~~~~
> 	src/roff/troff/hvunits.h: In function ‘vunits operator-(const vunits&, const vunits&)’:
> 	src/roff/troff/hvunits.h:114:7: error: ‘ckd_sub’ was not declared in this scope
> 	  114 |   if (ckd_sub(&r.n, r.n, y.n))
> 	      |       ^~~~~~~
> 	src/roff/troff/hvunits.h: In function ‘vunits operator-(const vunits&)’:
> 	src/roff/troff/hvunits.h:123:7: error: ‘ckd_mul’ was not declared in this scope
> 	  123 |   if (ckd_mul(&r.n, x.n, -1))
> 	      |       ^~~~~~~
> 	src/roff/troff/hvunits.h: In function ‘vunits operator*(const vunits&, int)’:
> 	src/roff/troff/hvunits.h:145:7: error: ‘ckd_mul’ was not declared in this scope
> 	  145 |   if (ckd_mul(&r.n, x.n, n))
> 	      |       ^~~~~~~
> 	src/roff/troff/hvunits.h: In function ‘vunits operator*(int, const vunits&)’:
> 	src/roff/troff/hvunits.h:154:7: error: ‘ckd_mul’ was not declared in this scope
> 	  154 |   if (ckd_mul(&r.n, n, x.n))
> 	      |       ^~~~~~~
> 	src/roff/troff/hvunits.h: In member function ‘units hunits::to_units()’:
> 	src/roff/troff/hvunits.h:208:7: error: ‘ckd_mul’ was not declared in this scope
> 	  208 |   if (ckd_mul(&r, n, hresolution))
> 	      |       ^~~~~~~
> 	src/roff/troff/hvunits.h: In function ‘hunits operator+(const hunits&, const hunits&)’:
> 	src/roff/troff/hvunits.h:222:7: error: ‘ckd_add’ was not declared in this scope
> 	  222 |   if (ckd_add(&r.n, r.n, y.n))
> 	      |       ^~~~~~~
> 	src/roff/troff/hvunits.h: In function ‘hunits operator-(const hunits&, const hunits&)’:
> 	src/roff/troff/hvunits.h:231:7: error: ‘ckd_sub’ was not declared in this scope
> 	  231 |   if (ckd_sub(&r.n, r.n, y.n))
> 	      |       ^~~~~~~
> 	src/roff/troff/hvunits.h: In function ‘hunits operator-(const hunits&)’:
> 	src/roff/troff/hvunits.h:241:7: error: ‘ckd_mul’ was not declared in this scope
> 	  241 |   if (ckd_mul(&r.n, x.n, -1))
> 	      |       ^~~~~~~
> 	src/roff/troff/hvunits.h: In function ‘hunits operator*(const hunits&, int)’:
> 	src/roff/troff/hvunits.h:263:7: error: ‘ckd_mul’ was not declared in this scope
> 	  263 |   if (ckd_mul(&r.n, x.n, n))
> 	      |       ^~~~~~~
> 	src/roff/troff/hvunits.h: In function ‘hunits operator*(int, const hunits&)’:
> 	src/roff/troff/hvunits.h:272:7: error: ‘ckd_mul’ was not declared in this scope
> 	  272 |   if (ckd_mul(&r.n, x.n, n))
> 	      |       ^~~~~~~
> 	src/roff/troff/div.cpp: In member function ‘virtual void macro_diversion::output(node*, bool, vunits, vunits, hunits)’:
> 	src/roff/troff/div.cpp:325:7: error: ‘ckd_add’ was not declared in this scope
> 	  325 |   if (ckd_add(&new_vpos, vpos, lineht))
> 	      |       ^~~~~~~
> 	make[2]: *** [Makefile:9395: src/roff/troff/div.o] Error 1
> 	make[2]: Leaving directory '/srv/alx/src/gnu/groff/master'
> 	make[1]: *** [Makefile:11776: all-recursive] Error 1
> 	make[1]: Leaving directory '/srv/alx/src/gnu/groff/master'
> 	make: *** [Makefile:6977: all] Error 2
> 
> Did you forget some #include?

It builds for me and others, like Deri and Grisha Levit.

https://lists.gnu.org/archive/html/groff/2025-10/msg00009.html

Have you "bootstrapped" lately?  That's necessary for Git users when we
bump the version of gnulib we include, which we probably did after
either 1.23.0.2695-49927 or 1.23.0.1254-19a18, and maybe both.  One
thing I do recall is bumping gnulib to get at the checked arithmetic
functions--precisely the ones you see above.

Also, FYI:

$ git describe origin/master
1.23.0-4017-g3ea378d35

I'll probably be bumping gnulib again soon--the version we're using hits
end-of-support in less than three months.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: groff build problem involving "ckd_mul" and "ckd_add"

[Alejandro Colomar]

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

Hi Branden,

On Mon, Oct 06, 2025 at 05:42:24AM -0500, G. Branden Robinson wrote:
> [looping in groff@gnu list]

[Actually looping in groff@gnu.org; I think you forgot.  :]

> [was: '^\}$' is (not) changed to a space character]

[...]

> > I tried building groff from git HEAD to see if that fixed the issues
> > in my server.  However, it seems groff doesn't build at the moment:
> > 
[...]
> > 
> > Did you forget some #include?
> 
> It builds for me and others, like Deri and Grisha Levit.
> 
> https://lists.gnu.org/archive/html/groff/2025-10/msg00009.html
> 
> Have you "bootstrapped" lately?  That's necessary for Git users when we
> bump the version of gnulib we include, which we probably did after
> either 1.23.0.2695-49927 or 1.23.0.1254-19a18, and maybe both.  One
> thing I do recall is bumping gnulib to get at the checked arithmetic
> functions--precisely the ones you see above.

Yes, I bootstrapped today.  I also ran 'git submodule update' prior to
that.

> 
> Also, FYI:
> 
> $ git describe origin/master
> 1.23.0-4017-g3ea378d35

I can reproduce both on my server (Debian) and on my desktop (Devuan).
I'm using Sid, so that may have something to do (maybe I have a more
recent compiler that errors where yours doesn't?).

	alx@devuan:~/src/gnu/groff/master$ git describe HEAD
	1.23.0-4017-g3ea378d35
	alx@devuan:~/src/gnu/groff/master$ git status
	On branch master
	Your branch is up to date with 'gnu/master'.

	nothing to commit, working tree clean
	alx@devuan:~/src/gnu/groff/master$ git submodule update
	alx@devuan:~/src/gnu/groff/master$ git submodule 
	 3fbc2c7bb371916a6f3433ef28d84874909d1052 gnulib (v1.0-1350-g3fbc2c7bb3)
	alx@devuan:~/src/gnu/groff/master$ set -o pipefail
	alx@devuan:~/src/gnu/groff/master$ time ./bootstrap |& wc -l; echo $?
	681

	real	0m5.284s
	user	0m3.950s
	sys	0m0.496s
	0
	alx@devuan:~/src/gnu/groff/master$ time ./configure |& wc -l; echo $?
	430

	real	0m11.332s
	user	0m8.099s
	sys	0m2.322s
	0
	alx@devuan:~/src/gnu/groff/master$ time make -j24 -k |& wc -l; echo $?
	1385

	real	0m4.765s
	user	0m35.467s
	sys	0m2.930s
	2
	alx@devuan:~/src/gnu/groff/master$ make
	make  all-recursive
	make[1]: Entering directory '/srv/alx/src/gnu/groff/master'
	make[2]: Entering directory '/srv/alx/src/gnu/groff/master'
	  CXX      src/roff/troff/div.o
	In file included from src/roff/troff/div.cpp:29:
	src/roff/troff/hvunits.h: In member function ‘units vunits::to_units()’:
	src/roff/troff/hvunits.h:91:7: error: ‘ckd_mul’ was not declared in this scope
	   91 |   if (ckd_mul(&r, n, vresolution))
	      |       ^~~~~~~
	src/roff/troff/hvunits.h: In function ‘vunits operator+(const vunits&, const vunits&)’:
	src/roff/troff/hvunits.h:105:7: error: ‘ckd_add’ was not declared in this scope
	  105 |   if (ckd_add(&r.n, r.n, y.n))
	      |       ^~~~~~~
	src/roff/troff/hvunits.h: In function ‘vunits operator-(const vunits&, const vunits&)’:
	src/roff/troff/hvunits.h:114:7: error: ‘ckd_sub’ was not declared in this scope
	  114 |   if (ckd_sub(&r.n, r.n, y.n))
	      |       ^~~~~~~
	src/roff/troff/hvunits.h: In function ‘vunits operator-(const vunits&)’:
	src/roff/troff/hvunits.h:123:7: error: ‘ckd_mul’ was not declared in this scope
	  123 |   if (ckd_mul(&r.n, x.n, -1))
	      |       ^~~~~~~
	src/roff/troff/hvunits.h: In function ‘vunits operator*(const vunits&, int)’:
	src/roff/troff/hvunits.h:145:7: error: ‘ckd_mul’ was not declared in this scope
	  145 |   if (ckd_mul(&r.n, x.n, n))
	      |       ^~~~~~~
	src/roff/troff/hvunits.h: In function ‘vunits operator*(int, const vunits&)’:
	src/roff/troff/hvunits.h:154:7: error: ‘ckd_mul’ was not declared in this scope
	  154 |   if (ckd_mul(&r.n, n, x.n))
	      |       ^~~~~~~
	src/roff/troff/hvunits.h: In member function ‘units hunits::to_units()’:
	src/roff/troff/hvunits.h:208:7: error: ‘ckd_mul’ was not declared in this scope
	  208 |   if (ckd_mul(&r, n, hresolution))
	      |       ^~~~~~~
	src/roff/troff/hvunits.h: In function ‘hunits operator+(const hunits&, const hunits&)’:
	src/roff/troff/hvunits.h:222:7: error: ‘ckd_add’ was not declared in this scope
	  222 |   if (ckd_add(&r.n, r.n, y.n))
	      |       ^~~~~~~
	src/roff/troff/hvunits.h: In function ‘hunits operator-(const hunits&, const hunits&)’:
	src/roff/troff/hvunits.h:231:7: error: ‘ckd_sub’ was not declared in this scope
	  231 |   if (ckd_sub(&r.n, r.n, y.n))
	      |       ^~~~~~~
	src/roff/troff/hvunits.h: In function ‘hunits operator-(const hunits&)’:
	src/roff/troff/hvunits.h:241:7: error: ‘ckd_mul’ was not declared in this scope
	  241 |   if (ckd_mul(&r.n, x.n, -1))
	      |       ^~~~~~~
	src/roff/troff/hvunits.h: In function ‘hunits operator*(const hunits&, int)’:
	src/roff/troff/hvunits.h:263:7: error: ‘ckd_mul’ was not declared in this scope
	  263 |   if (ckd_mul(&r.n, x.n, n))
	      |       ^~~~~~~
	src/roff/troff/hvunits.h: In function ‘hunits operator*(int, const hunits&)’:
	src/roff/troff/hvunits.h:272:7: error: ‘ckd_mul’ was not declared in this scope
	  272 |   if (ckd_mul(&r.n, x.n, n))
	      |       ^~~~~~~
	src/roff/troff/div.cpp: In member function ‘virtual void macro_diversion::output(node*, bool, vunits, vunits, hunits)’:
	src/roff/troff/div.cpp:325:7: error: ‘ckd_add’ was not declared in this scope
	  325 |   if (ckd_add(&new_vpos, vpos, lineht))
	      |       ^~~~~~~
	make[2]: *** [Makefile:9395: src/roff/troff/div.o] Error 1
	make[2]: Leaving directory '/srv/alx/src/gnu/groff/master'
	make[1]: *** [Makefile:11776: all-recursive] Error 1
	make[1]: Leaving directory '/srv/alx/src/gnu/groff/master'
	make: *** [Makefile:6977: all] Error 2


Cheers,
Alex

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: groff build problem involving "ckd_mul" and "ckd_add"

[Collin Funk]

Alejandro Colomar <alx@kernel.org> writes:

>> It builds for me and others, like Deri and Grisha Levit.
>> 
>> https://lists.gnu.org/archive/html/groff/2025-10/msg00009.html
>> 
>> Have you "bootstrapped" lately?  That's necessary for Git users when we
>> bump the version of gnulib we include, which we probably did after
>> either 1.23.0.2695-49927 or 1.23.0.1254-19a18, and maybe both.  One
>> thing I do recall is bumping gnulib to get at the checked arithmetic
>> functions--precisely the ones you see above.
>
> Yes, I bootstrapped today.  I also ran 'git submodule update' prior to
> that.
>
>> 
>> Also, FYI:
>> 
>> $ git describe origin/master
>> 1.23.0-4017-g3ea378d35
>
> I can reproduce both on my server (Debian) and on my desktop (Devuan).
> I'm using Sid, so that may have something to do (maybe I have a more
> recent compiler that errors where yours doesn't?).

This was discussed and fixed in Gnulib a few months ago [1]. I assume
you are using g++ 15 and the others are not.

Here are the relevant commits:

    $ git branch --contains=7ee6e40b6730c87e5c1323bb5c2564bcb6eff9e4
    * master
      stable-202507
    $ git branch --contains=e331531a771443edae4135e6bcd016282cf1a3aa
    * master
      stable-202507

But groff is using a branch that does not contain them:

    commit e3ff929ddea95e0fc9fe7ea3541d28665de42370
    Author:     G. Branden Robinson <g.branden.robinson@gmail.com>
    AuthorDate: Fri Mar 28 03:10:49 2025 -0500
    Commit:     G. Branden Robinson <g.branden.robinson@gmail.com>
    CommitDate: Sat Mar 29 22:27:32 2025 -0500
    
        gnulib: Update stable/2025-01 branch.
        
        ...to commit 3fbc2c7bb3, 3 March.

Using the following command I can make ./bootstrap use the master branch
from my local checkout to copy files:

    $ env GNULIB_SRCDIR=$HOME/.local/src/gnulib ./bootstrap

Allows me to build groff fine with g++ 15.

Collin

[1] https://lists.gnu.org/archive/html/bug-gnulib/2025-05/msg00207.html

Re: groff build problem involving "ckd_mul" and "ckd_add"

[Alejandro Colomar]

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

Hi Collin,

On Mon, Oct 06, 2025 at 07:06:39PM -0700, Collin Funk wrote:
> > I can reproduce both on my server (Debian) and on my desktop (Devuan).
> > I'm using Sid, so that may have something to do (maybe I have a more
> > recent compiler that errors where yours doesn't?).
> 
> This was discussed and fixed in Gnulib a few months ago [1]. I assume
> you are using g++ 15 and the others are not.

Yup, that sounds like it.  I'm using

	g++ (Debian 15.2.0-4) 15.2.0

> Here are the relevant commits:
> 
>     $ git branch --contains=7ee6e40b6730c87e5c1323bb5c2564bcb6eff9e4
>     * master
>       stable-202507
>     $ git branch --contains=e331531a771443edae4135e6bcd016282cf1a3aa
>     * master
>       stable-202507
> 
> But groff is using a branch that does not contain them:
> 
>     commit e3ff929ddea95e0fc9fe7ea3541d28665de42370
>     Author:     G. Branden Robinson <g.branden.robinson@gmail.com>
>     AuthorDate: Fri Mar 28 03:10:49 2025 -0500
>     Commit:     G. Branden Robinson <g.branden.robinson@gmail.com>
>     CommitDate: Sat Mar 29 22:27:32 2025 -0500
>     
>         gnulib: Update stable/2025-01 branch.
>         
>         ...to commit 3fbc2c7bb3, 3 March.
> 
> Using the following command I can make ./bootstrap use the master branch
> from my local checkout to copy files:
> 
>     $ env GNULIB_SRCDIR=$HOME/.local/src/gnulib ./bootstrap
> 
> Allows me to build groff fine with g++ 15.

Thanks!

Branden, would you mind bumping the gnulib version sooner than later to
avoid using workarounds?  That would also allow us to use countof()
sooner.


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: groff build problem involving "ckd_mul" and "ckd_add"

[G. Branden Robinson]

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

At 2025-10-07T10:47:43+0200, Alejandro Colomar wrote:
> On Mon, Oct 06, 2025 at 07:06:39PM -0700, Collin Funk wrote:
> > Using the following command I can make ./bootstrap use the master
> > branch from my local checkout to copy files:
> > 
> >     $ env GNULIB_SRCDIR=$HOME/.local/src/gnulib ./bootstrap
> > 
> > Allows me to build groff fine with g++ 15.
> 
> Thanks!
> 
> Branden, would you mind bumping the gnulib version sooner than later
> to avoid using workarounds?  That would also allow us to use countof()
> sooner.

Done!

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: groff build problem involving "ckd_mul" and "ckd_add"

[Alejandro Colomar]

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

Hi Branden,

On Tue, Oct 07, 2025 at 03:06:36PM -0500, G. Branden Robinson wrote:
> > Branden, would you mind bumping the gnulib version sooner than later
> > to avoid using workarounds?  That would also allow us to use countof()
> > sooner.
> 
> Done!

Thanks!  Do you want a patch for using countof() tonight?


Cheers,
Alex

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: groff build problem involving "ckd_mul" and "ckd_add"

[G. Branden Robinson]

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

At 2025-10-07T22:24:19+0200, Alejandro Colomar wrote:
> Thanks!  Do you want a patch for using countof() tonight?

No hurry!  ;-)

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: groff build problem involving "ckd_mul" and "ckd_add"

[Alejandro Colomar]

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

Hi Branden,

On Tue, Oct 07, 2025 at 03:29:28PM -0500, G. Branden Robinson wrote:
> At 2025-10-07T22:24:19+0200, Alejandro Colomar wrote:
> > Thanks!  Do you want a patch for using countof() tonight?
> 
> No hurry!  ;-)

I have it almost ready.  I'll finish it in an hour or so.  If you're
ready to apply it, I'd like to have it tonight if we can.  :-)


Have a lovely night!
Alex

> 
> Regards,
> Branden



-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]