groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alejandro Colomar
Subject: Re: [RFC] input.cpp: Remove use of strncat(3)
Date: Tue, 6 Dec 2022 00:16:18 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1

Hi Steffen,

On 12/6/22 00:11, Steffen Nurpmeso wrote:
Alejandro Colomar wrote in
  <20221205223936.8290-1-alx@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_PREFIX)];
  |    strcpy(s, MACRO_PREFIX);
  |-       strncat(s, fn, fnlen - sizeof(MACRO_POSTFIX) + 1);
  |+          strlcat(s, fn, sizeof(MACRO_PREFIX));
  |    fp = mac_path->open_file(s, &path);
  |    delete[] s;


To me this looks like a perfect usage of simple memcpy() since

Yes, memcpy(3) would be fine too. Although, that hurts readability a little bit, since memcpy(3) doesn't tell so much that you're dealing with (NUL-terminated) string. Since performance is not a big deal here, I guess strlcpy(3) would be just fine. But yes, I'd very much prefer memcpy(3) over strncpy(3).

both lengths are known.
Maybe even better would be a C++ string type so you could do
mac_path->open_file(resize().append().append().cp()), but this
seems off topic.

Can't comment, since I don't know C++. Keeping C-compatibility is a nice have, but I don't know how much of C++ strings groff already uses, so do what you have to do.

Cheers,

Alex


--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

--
<http://www.alejandro-colomar.es/>

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]