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

DISCUSSION Bjarni Ingi Gislason 4 participants 23 messages Sep 30, 2025 – Oct 7, 2025 Man-pages: manual pages for Linux -- Sections 2, 3, 4, 5, and 7

lore

Share & tools

lore

Bjarni Ingi Gislason

author

2025-09-30 18:18 UTC #0 lore raw

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.

Alejandro Colomar

maintainer

2025-09-30 18:46 UTC #1 lore raw

Hi Bjarni,

Quoted 39 lines · 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.

Quoted 8 lines

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

Signature · 2 lines

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

Bjarni Ingi Gislason

author

2025-09-30 22:37 UTC #2 lore raw

A patch is superfluous

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

Alejandro Colomar

maintainer

2025-10-01 06:49 UTC #3 lore raw

Hi Bjarni.

Quoted 3 lines · Bjarni Ingi Gislason

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

Signature · 2 lines

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

Bjarni Ingi Gislason

author

2025-10-02 21:57 UTC #4 lore raw

Quoted 5 lines · Alejandro Colomar

Hi Bjarni.
Quoted 2 lines · Bjarni Ingi Gislason
A patch is superfluous

Quoted 9 lines

Quoted 1 line
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.

G. Branden Robinson

2025-09-30 19:40 UTC #5 lore raw

In reply to Bjarni Ingi Gislason

Quoted 1 line · Bjarni Ingi Gislason

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,

Quoted 4 lines

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.

[...]

Quoted 2 lines

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.

Quoted 2 lines

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:

man/man7/vdso.7 +3 -8

index 0dc8bf6f2..88a561222 100644
@@ -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.

man/man7/vdso.7 +3 -8

index 0dc8bf6f2..750119996 100644
@@ -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.

Quoted 1 line

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

G. Branden Robinson

2025-09-30 19:44 UTC #6 lore raw

Quoted 7 lines · G. Branden Robinson

...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

Alejandro Colomar

maintainer

2025-10-02 22:25 UTC #7 lore raw

In reply to G. Branden Robinson

Hi Branden,

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

Have a lovely night!
Alex

Quoted 157 lines · G. Branden Robinson

Quoted 1 line · Bjarni Ingi Gislason
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,
Quoted 4 lines
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.
[...]
Quoted 2 lines
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.
Quoted 2 lines
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:
man/man7/vdso.7 +3 -8
index 0dc8bf6f2..88a561222 100644
@@ -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.
man/man7/vdso.7 +3 -8
index 0dc8bf6f2..750119996 100644
@@ -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.
Quoted 1 line
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

Signature · 2 lines

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

Alejandro Colomar

maintainer

2025-10-04 09:16 UTC #8 lore raw

In reply to G. Branden Robinson

Hi Branden,

Quoted 8 lines · G. Branden Robinson

...but my recommendation is be the following.
man/man7/vdso.7 +0 -0
index 0dc8bf6f2..750119996 100644
@@ -141,11 +141,10 @@ .SS vDSO names
 .BR ldd (1)

man/man7/vdso.7 .SS vDSO names · line 147

Quoted 10 lines

man/man7/vdso.7 +3 -4

 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'.

Quoted 4 lines

man/man7/vdso.7 +0 -0

 user ABI       vDSO name
 _
 aarch64        linux\-vdso.so.1

man/man7/vdso.7 .SS vDSO names · line 166

Quoted 10 lines

man/man7/vdso.7 +0 -4

@@ -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 <[email protected]>
	Date:   Sat Oct 4 10:48:02 2025 +0200

	    man/man7/vdso.7: ffix
	    
	    Reported-by: Bjarni Ingi Gislason <[email protected]>
	    Suggested-by: "G. Branden Robinson" <[email protected]>
	    Signed-off-by: Alejandro Colomar <[email protected]>

	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>

Quoted 1 line

...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

Signature · 2 lines

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

G. Branden Robinson

2025-10-04 09:42 UTC #9 lore raw

Hi Alex,

At 2025-10-04T11:16:06+0200, Alejandro Colomar wrote:
[snip]

Quoted 6 lines

man/man7/vdso.7 .SS vDSO names
Quoted 3 lines
man/man7/vdso.7 +2 -1
-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"...

Quoted 3 lines

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_. ;-)

Quoted 3 lines

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.

Quoted 7 lines

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>
Quoted 1 line
...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

Alejandro Colomar

maintainer

2025-10-04 10:30 UTC #10 lore raw

Hi Branden,

Quoted 11 lines · G. Branden Robinson

Hi Alex,
At 2025-10-04T11:16:06+0200, Alejandro Colomar wrote:
[snip]
Quoted 6 lines
man/man7/vdso.7 .SS vDSO names
Quoted 3 lines
man/man7/vdso.7 +2 -1
-l l.
+Lb Lb
+L  L .o
For consistency with the rest of the project, I've used 'lB' instead of 'Lb'.

Quoted 4 lines

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.

Quoted 8 lines

And consistency is king. :) Or co-king with "clarity"...
Quoted 3 lines
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_. ;-)

Quoted 8 lines

Quoted 3 lines
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.

Quoted 9 lines

Quoted 7 lines
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>
Quoted 1 line
...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. :)

Quoted 2 lines

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

Signature · 2 lines

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

G. Branden Robinson

2025-10-05 13:48 UTC #11 lore raw

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

In reply to G. Branden Robinson

Hi Alex,

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

Quoted 9 lines · G. Branden Robinson

Quoted 3 lines · Alejandro Colomar
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.

Alejandro Colomar

maintainer

2025-10-05 18:47 UTC #12 lore raw

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

Hi Branden,

Quoted 9 lines · G. Branden Robinson

Hi Alex,
First I must correct the subject line. '^\}$' is not "changed to a space character". I explain below.
Quoted 3 lines · G. Branden Robinson
Quoted 1 line · Alejandro Colomar
BTW, in the PDF, the '.P' doesn't seem to be working.

URL edited:

Quoted 1 line

Quoted 1 line
Quoted 1 line
<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.

Quoted 32 lines

Quoted 4 lines
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---

Quoted 5 lines

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 <[email protected]>
	Date:   Sat Oct 4 10:48:02 2025 +0200

	    man/man7/vdso.7: ffix
	    
	    Reported-by: Bjarni Ingi Gislason <[email protected]>
	    Suggested-by: "G. Branden Robinson" <[email protected]>
	    Signed-off-by: Alejandro Colomar <[email protected]>

	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.

Quoted 16 lines

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.)

Quoted 2 lines

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

Quoted 23 lines

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.

Signature · 2 lines

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

G. Branden Robinson

2025-10-06 08:51 UTC #13 lore raw

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

Hi Alex,

Quoted 7 lines · Alejandro Colomar

URL edited:
Quoted 1 line
Quoted 1 line
Quoted 1 line
<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".

Quoted 8 lines

Quoted 5 lines
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:

[...]

Quoted 4 lines

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

[...]

Quoted 2 lines

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

Alejandro Colomar

maintainer

2025-10-06 10:25 UTC #14 lore raw

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

Hi Branden,

Quoted 11 lines · G. Branden Robinson

Quoted 4 lines
	-.if t \{\
	-.ft CW
	-\}
	+.P
[...]
Quoted 2 lines
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

Signature · 2 lines

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

G. Branden Robinson

2025-10-06 10:42 UTC #15 lore raw

groff build problem involving "ckd_mul" and "ckd_add"

[looping in groff@gnu list]

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

Hi Alex,

Quoted 14 lines · Alejandro Colomar

Quoted 2 lines · G. Branden Robinson
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

Quoted 7 lines

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.

Quoted 67 lines

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

Quoted 1 line

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

Alejandro Colomar

maintainer

2025-10-06 11:11 UTC #16 lore raw

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

Hi Branden,

Quoted 1 line · G. Branden Robinson

[looping in groff@gnu list]

[Actually looping in [email protected]; I think you forgot. :]

Quoted 1 line

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

[...]

Quoted 3 lines

Quoted 3 lines
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:

[...]

Quoted 5 lines

Quoted 2 lines
Did you forget some #include?
It builds for me and others, like Deri and Grisha Levit.

Quoted 7 lines

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.

Quoted 5 lines

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

Signature · 2 lines

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

Collin Funk

2025-10-07 02:06 UTC #17 lore raw

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

Quoted 14 lines · Alejandro Colomar

Quoted 9 lines
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.
Quoted 1 line

Quoted 8 lines

Quoted 4 lines
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 <[email protected]>
    AuthorDate: Fri Mar 28 03:10:49 2025 -0500
    Commit:     G. Branden Robinson <[email protected]>
    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

Alejandro Colomar

maintainer

2025-10-07 08:47 UTC #18 lore raw

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

Hi Collin,

Quoted 6 lines · Collin Funk

Quoted 3 lines
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

Quoted 21 lines

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 <[email protected]>
    AuthorDate: Fri Mar 28 03:10:49 2025 -0500
    Commit:     G. Branden Robinson <[email protected]>
    CommitDate: Sat Mar 29 22:27:32 2025 -0500
    
        gnulib: Update stable/2025-01 branch.
        
        ...to commit 3fbc2c7bb3, 3 March.

Quoted 6 lines

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

Signature · 2 lines

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

G. Branden Robinson

2025-10-07 20:06 UTC #19 lore raw

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

Quoted 6 lines · Alejandro Colomar

Quoted 5 lines · Collin Funk
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

Quoted 7 lines

Quoted 1 line
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

Alejandro Colomar

maintainer

2025-10-07 20:24 UTC #20 lore raw

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

Hi Branden,

Quoted 5 lines · G. Branden Robinson

Quoted 3 lines
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

Signature · 2 lines

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

G. Branden Robinson

2025-10-07 20:29 UTC #21 lore raw

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

Quoted 1 line · Alejandro Colomar

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

No hurry! ;-)

Regards,
Branden

Alejandro Colomar

maintainer

2025-10-07 21:10 UTC #22 lore raw

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

Hi Branden,

Quoted 4 lines · G. Branden Robinson

Quoted 1 line · Alejandro Colomar
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

Quoted 3 lines

Regards,
Branden

Signature · 2 lines

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