Linux Manual Pages development
 help / color / mirror / Atom feed
From: Lennart Jablonka <humm@ljabl.com>
To: Alejandro Colomar <alx@kernel.org>
Cc: linux-man@vger.kernel.org
Subject: [PATCH] string_copying.7: don't grant strl{cpy,cat} magic
Date: Fri, 28 Jul 2023 19:22:10 +0000	[thread overview]
Message-ID: <ZMQVYtquNN-s0IJr@beryllium> (raw)

A function can't check whether a pointer points to the start of a
string.  What it certainly can do is to keep reading until you either
find a null byte or read the secret key that lies adjacent in memory and
post it to your favorite mailing list.

strlcpy and strlcat behave the exact same way any other function
accepting a string behaves:  If you don't pass a string, the behavior is
undefined.  And that, I believe, does not deserve a special mention
here, seeing as all the other string functions don't get such a mention
either.

Signed-off-by: Lennart Jablonka <humm@ljabl.com>
---
Hey Alex!

I don't dislike string_copying(7) overall.  This is one of the parts of
the content that I dislike---it is false, after all.  Besides that:

The "definitions" at the top don't make it clear enough that they aren't
supposed to be precise definitions used in your usual C jargon; that
while string and a string's length and an object's size are defined
by C, and while you understand and sometimes use most of these terms,
there is no norm that says "When you talk about a pointer to one past
a buffer's last byte, you call it 'end'!"  That there is no norm that
says "When you say 'copy,' you write to the beginning, not to
elsewhere!"

Furthermore, the terminology around "character sequences" confused me
while reading the page.  When do you have a buffer, neither
null-terminated nor null-padded, that is defined not to contain null
bytes?  And how do functions behave that want a character sequence if
that does contain a null byte?  Do they take the null byte to signal the
character sequence's end?  Need they accept the null byte as part of the
character sequence?  Is the behavior undefined?

And lastly, the man page doesn't list the functions' standards or who
invented them.

 man7/string_copying.7 | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/man7/string_copying.7 b/man7/string_copying.7
index 04426ef77..308cada36 100644
--- a/man7/string_copying.7
+++ b/man7/string_copying.7
@@ -223,8 +223,7 @@ It only requires to check for truncation once after all chained calls.
 .BR strlcpy (3bsd)
 and
 .BR strlcat (3bsd)
-are designed to crash if the input string is invalid
-(doesn't contain a terminating null byte).
+are similar, but less efficient when chained.
 .IP \[bu]
 .BR stpncpy (3)
 and
@@ -410,9 +409,6 @@ isn't large enough to hold the copy,
 the resulting string is truncated
 (but it is guaranteed to be null-terminated).
 They return the length of the total string they tried to create.
-These functions force a SIGSEGV if the
-.I src
-pointer is not a string.
 .IP
 .BR stpecpy (3)
 is a simpler alternative to these functions.
-- 
2.41.0

             reply	other threads:[~2023-07-28 19:22 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-28 19:22 Lennart Jablonka [this message]
2023-07-28 22:05 ` [PATCH] string_copying.7: don't grant strl{cpy,cat} magic Alejandro Colomar
2023-07-28 23:51   ` Lennart Jablonka
2023-07-29 12:04     ` Alejandro Colomar
2023-07-29 14:38       ` Matthew House
2023-07-29 14:47         ` Lennart Jablonka
2023-07-29 21:06           ` Matthew House
2023-07-29 19:39         ` G. Branden Robinson
2023-07-30 14:05           ` Alejandro Colomar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZMQVYtquNN-s0IJr@beryllium \
    --to=humm@ljabl.com \
    --cc=alx@kernel.org \
    --cc=linux-man@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox