From: Segher Boessenkool <segher@kernel.crashing.org>
To: "Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>
Cc: Jonny Grant <jg@jguk.org>,
gcc-help@gcc.gnu.org, linux-man <linux-man@vger.kernel.org>,
Florian Weimer <fw@deneb.enyo.de>,
Michael Kerrisk <mtk.manpages@gmail.com>
Subject: Re: strlen
Date: Fri, 9 Jul 2021 20:00:54 -0500 [thread overview]
Message-ID: <20210710010054.GY1583@gate.crashing.org> (raw)
In-Reply-To: <fbd62475-fa04-d26e-7d58-bc96180f7e4c@gmail.com>
Fine, I'll bite :-)
On Fri, Jul 09, 2021 at 04:17:08PM +0200, Alejandro Colomar (man-pages) wrote:
> On 7/9/21 3:54 PM, Jonny Grant wrote:
> >Yes, this could work. But it does rely on programmer typing it like that
> >every time... Maybe an inline function better.
>
> I agree on that.
A function (or any other abstraction) can be fine for this, *iff* you
can make people use it correctly. Since it is pretty much impossible to
give a good succinct name to this function, I posit that is not the
case. Please feel free to prove me wrong (by coming up with a decent
name for it).
> >I'd prefer a Annex K of C11 style function ISO/IEC TR 24731-1 for strlen()
> >- but there isn't one such as strnlen_s.
>
> Please, consider not calling some function safesomething() or similar,
> as it isn't 100% safe. It's like calling some thing "the new X". How
> will you call the next version? "the nova X"? And the next? "the
> supernew X"?
>
> As I said before, unsigned types are unsafe, you may want to accept it
> or not, but they are.
I thought Annex K was great entertainment, but calling unsigned types
"unsafe" takes the cake.
Unsigned types are Z/nZ with n some power of two. Signed types are not
even Z (overflow is undefined). Unsigned types are useful for
describing many machine things. They are useful for sizes, not only
because sizes cannot be negative, but also because sizes can be bigger
than the maximum positive number that can fit in the same size signed
number. They are useful for bitty things, registers maybe, stuff in
memory, or device I/O registers. And they are much more useful than C
signed numbers for holding memory addresses, where you need that (you
can do sane aritmetic on it).
Using unsigned types without range checking is often wrong ("unsafe" in
your words). Using signed types without range checking is just as wrong
in the same cases, if not more (overflow is undefined). At least in the
"unsigned" case it is *possible* its behaviour is what the programmer
intended!
> Agree on this again, but I think the following is readable:
>
> len = strlennull(maybenull);
If you use it a million times, of course you can give it a short and
non-sensical name, and expect the users to learn what it means. If not,
it is better to be slightly more verbose, and reduce the mental load.
Segher
next prev parent reply other threads:[~2021-07-10 1:05 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-04 18:01 strlen Jonny Grant
2020-09-04 19:21 ` strlen Florian Weimer
2020-09-04 23:14 ` strlen Jonny Grant
2020-09-05 7:12 ` strlen Florian Weimer
2021-07-06 20:30 ` strlen Jonny Grant
2021-07-06 22:11 ` strlen Florian Weimer
2021-07-07 11:36 ` strlen Jonny Grant
2021-07-07 12:22 ` strlen Alejandro Colomar (man-pages)
2021-07-07 12:31 ` strlen Alejandro Colomar (man-pages)
2021-07-07 13:31 ` strlen Jonny Grant
2021-07-07 16:57 ` strlen Alejandro Colomar (man-pages)
2021-07-07 17:23 ` strlen Alejandro Colomar (man-pages)
2021-07-07 17:33 ` strlen Alejandro Colomar (man-pages)
2021-07-09 13:48 ` strlen Jonny Grant
2021-07-08 10:07 ` strlen Jonny Grant
2021-07-08 11:06 ` strlen Alejandro Colomar (man-pages)
2021-07-08 12:13 ` strlen Xi Ruoyao
2021-07-08 23:49 ` strlen Segher Boessenkool
2021-07-09 13:54 ` strlen Jonny Grant
2021-07-09 14:17 ` strlen Alejandro Colomar (man-pages)
2021-07-09 16:11 ` strlen Xi Ruoyao
2021-07-10 1:00 ` Segher Boessenkool [this message]
2021-07-09 10:50 ` strlen Jonny Grant
2021-07-09 11:27 ` strlen Alejandro Colomar (man-pages)
2021-07-09 11:43 ` strlen Alejandro Colomar (man-pages)
[not found] ` <1627912755.3783669.1625745946723@mail.yahoo.com>
[not found] ` <59a70222-a46f-1e65-c9db-6c9e577c8adc@126.com>
2021-07-09 17:26 ` strlen Martin Sebor
2021-07-09 20:19 ` strlen Alejandro Colomar (man-pages)
2021-07-09 20:44 ` strlen Jonny Grant
2021-07-10 18:37 ` strlen Alejandro Colomar (man-pages)
2021-07-10 20:49 ` strlen Jonny Grant
2021-07-10 21:36 ` strlen Alejandro Colomar (man-pages)
2021-07-12 21:16 ` strlen Jonny Grant
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=20210710010054.GY1583@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=alx.manpages@gmail.com \
--cc=fw@deneb.enyo.de \
--cc=gcc-help@gcc.gnu.org \
--cc=jg@jguk.org \
--cc=linux-man@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).