On Fri, 16 Dec 2022 at 00:43, Eric S. Raymond wrote:
> Dave Kemper :
> > Eric, can reposurgeon retroactively add an earlier release to git
> > without changing all the existing git hashes (which are referenced all
> > over the place, in the bug tracker and elsewhere)? I know nothing
> > about how
Dave Kemper :
> Eric, can reposurgeon retroactively add an earlier release to git
> without changing all the existing git hashes (which are referenced all
> over the place, in the bug tracker and elsewhere)? I know nothing
> about how these hashes are generated, so this may be utterly
> infeasible
On Sun, Dec 11, 2022 at 07:50:37PM -0600, Dave Kemper wrote:
> [dropping Alex from Cc]
>
> On 12/10/22, G. Branden Robinson wrote:
> > Thanks to TUHS, I can dig back even farther than the dawn of our
> > repository's history (groff 1.02) and gaze upon groff 1.01.[1]
> ...
> > [1]
> > https://minn
[dropping Alex from Cc]
On 12/10/22, G. Branden Robinson wrote:
> Thanks to TUHS, I can dig back even farther than the dawn of our
> repository's history (groff 1.02) and gaze upon groff 1.01.[1]
...
> [1]
> https://minnie.tuhs.org/cgi-bin/utree.pl?file=Net2/usr/src/usr.bin/groff/VERSION
When Er
[dropping Larry from Cc because we don't appear to have significant
common ground in this discussion]
I had this mentally queued for reply; thanks, Dave, for writing and
prompting me to finally shift on it. :)
At 2022-12-09T15:52:11-0600, Dave Kemper wrote:
> I have no opinion about this particu
I have no opinion about this particular change, but to address this
general point:
On 12/5/22, Larry McVoy wrote:
> I used to run a company that did source management tools and we strongly
> discouraged these sorts of "clean ups" because they change the author
> of that line of code. Our system
Hi Larry,
On 12/6/22 00:45, Larry McVoy wrote:
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?
Well,
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
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
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
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
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
12 matches
Mail list logo
