Re: [RFC] input.cpp: Remove use of strncat(3)

2022-12-05 Thread Larry McVoy
On Mon, Dec 05, 2022 at 11:39:37PM +0100, Alejandro Colomar wrote: > See the strncat(3) Linux manual page for details about why strncat(3) > is actively harmful. Is there a a known instance of strncpy() causing a problem in the groff source? I get it, you are fixing a possible problem and there m

Re: [RFC] input.cpp: Remove use of strncat(3)

2022-12-05 Thread Alejandro Colomar
Hi Steffen, On 12/6/22 00:11, Steffen Nurpmeso wrote: Alejandro Colomar wrote in <20221205223936.8290-1-...@kernel.org>: ... |--- a/src/roff/troff/input.cpp |+++ b/src/roff/troff/input.cpp |@@ -7892,7 +7892,7 @@ void do_macro_source(bool quietly) |MACRO_POSTFIX, sizeof(MACRO_POST

Re: [RFC] input.cpp: Remove use of strncat(3)

2022-12-05 Thread Steffen Nurpmeso
Alejandro Colomar wrote in <20221205223936.8290-1-...@kernel.org>: ... |--- a/src/roff/troff/input.cpp |+++ b/src/roff/troff/input.cpp |@@ -7892,7 +7892,7 @@ void do_macro_source(bool quietly) |MACRO_POSTFIX, sizeof(MACRO_POSTFIX) - 1) == 0) { |char *s = new char[fnlen + sizeof(MACRO

Re: [RFC] input.cpp: Remove use of strncat(3)

2022-12-05 Thread Alejandro Colomar
On 12/5/22 23:54, Alejandro Colomar wrote: On 12/5/22 23:39, Alejandro Colomar wrote: See the strncat(3) Linux manual page for details about why strncat(3) is actively harmful. Still, we don't test for truncation, which is a sign that strlcpy(3) (or strncpy(3)) before it were incorrectly us

Re: [RFC] input.cpp: Remove use of strncat(3)

2022-12-05 Thread Alejandro Colomar
On 12/5/22 23:39, Alejandro Colomar wrote: See the strncat(3) Linux manual page for details about why strncat(3) is actively harmful. Still, we don't test for truncation, which is a sign that strlcpy(3) (or strncpy(3)) before it were incorrectly used, but that should be addressed in a separate

[RFC] input.cpp: Remove use of strncat(3)

2022-12-05 Thread Alejandro Colomar
See the strncat(3) Linux manual page for details about why strncat(3) is actively harmful. Still, we don't test for truncation, which is a sign that strlcpy(3) (or strncpy(3)) before it were incorrectly used, but that should be addressed in a separate patch. Of course, strncpy(3) wasn't tested fo

RIP strncpy(3) and strncat(3)

2022-12-05 Thread Alejandro Colomar
Hi Branden, You probably have seen my radical changes regarding string copy functions. I've seen that groff uses strncpy(3) in a few places, and strncat(3) in one: $ grep -rn strncpy src/ src/libs/libdriver/input.cpp:1038: strncpy((char *)current_filename, (char *)fname, len); src/libs/libdr

Re: Issue in man page ascii.7

2022-12-05 Thread Alejandro Colomar
Hi Branden, On 12/5/22 15:06, G. Branden Robinson wrote: [...] You're welcome, but I think we might have talked past each other below. Sure, I try to do it consistently. If I Cc you is a "just read it if you want, not forced, maybe you're busy and someone else on groff@ picks it up". :) W

Re: Issue in man page ascii.7

2022-12-05 Thread G. Branden Robinson
Hi Alex, At 2022-12-05T13:35:42+0100, Alejandro Colomar wrote: > On 12/5/22 09:15, G. Branden Robinson wrote: > > [[The fix]] would be something like this: > > > > -3: # 3 C S c s 3: ! + 5 ? I S ] g q {\n" > > +3: # 3 C S c s 3: !\& + 5 ?\& I S ] g q {\n" > > -6: & 6

Re: Issue in man page ascii.7

2022-12-05 Thread Alejandro Colomar
Hi Branden! On 12/5/22 09:15, G. Branden Robinson wrote: Hi Alex & Helge, [...] It would be something like this: -3: # 3 C S c s 3: ! + 5 ? I S ] g q {\n" +3: # 3 C S c s 3: !\& + 5 ?\& I S ] g q {\n" -6: & 6 F V f v 6: $ . 8 B L V \\` j t \\(ti\

Re: Issue in man page ascii.7

2022-12-05 Thread G. Branden Robinson
Hi Alex & Helge, At 2022-12-04T13:53:41+0100, Alejandro Colomar wrote: > On 12/4/22 10:07, Helge Kreutzmann wrote: > > Without further ado, the following was found: [...] > > " 2 3 4 5 6 7 30 40 50 60 70 80 90 100 110 120\n" > > " - -\n" > >