From: Andreas Schwab <schwab@suse.de>
To: Job Snijders <job@fastly.com>
Cc: Florian Weimer <fweimer@redhat.com>, libc-alpha@sourceware.org
Subject: Re: [PATCH] resolv: add IPv6 support to inet_net_pton()
Date: Mon, 25 Mar 2024 09:45:03 +0100 [thread overview]
Message-ID: <mvm5xxahf8w.fsf@suse.de> (raw)
In-Reply-To: <Zf0GHKlYs8d8PkEY@feather.sobornost.net> (Job Snijders's message of "Fri, 22 Mar 2024 04:16:28 +0000")
On Mär 22 2024, Job Snijders wrote:
> The above to me means that it is not enough to just check whether errno
> is set to ERANGE, but one also has to check whether LONG_MAX or LONG_MIN
> were returned. It's an 'AND' operation.
That is irrelevant.
> Then, if errno is NOT set to ERANGE, then we have to additionally check
> whether the value is within contextual bounds.
By checking the range you already know that the value is neither
LONG_MAX nor LONG_MIN, thus the errno value does not matter. This is
simple logic.
> So I don't think it is correct to skimp on checks here, to me idiomatic
> checks do not equate 'bad'.
A source analyzer will likely flag it, which makes it even worse.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
prev parent reply other threads:[~2024-03-25 8:45 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-22 17:54 Job Snijders
2022-12-22 18:21 ` Florian Weimer
2022-12-22 18:28 ` copying a string with truncation (was: [PATCH] resolv: add IPv6 support to inet_net_pton()) Alejandro Colomar
2022-12-22 20:25 ` Alejandro Colomar
2022-12-23 6:55 ` Sam James
2022-12-23 7:00 ` Sam James
2022-12-23 11:42 ` Alejandro Colomar
2022-12-23 11:45 ` Alejandro Colomar
2022-12-31 15:11 ` Sam James
2023-01-17 10:56 ` [PATCH] resolv: add IPv6 support to inet_net_pton() Job Snijders
2023-04-19 11:31 ` Job Snijders
2024-03-17 1:23 ` Job Snijders
2024-03-17 3:19 ` Job Snijders
2024-03-17 11:18 ` Florian Weimer
2024-03-18 8:59 ` Job Snijders
2024-03-18 9:23 ` Andreas Schwab
2024-03-18 23:01 ` Job Snijders
2024-03-19 8:20 ` Andreas Schwab
2024-03-19 8:29 ` Job Snijders
2024-03-19 9:50 ` Andreas Schwab
2024-03-22 4:16 ` Job Snijders
2024-03-22 14:24 ` Zack Weinberg
2024-03-25 9:04 ` Job Snijders
2024-04-14 14:56 ` Job Snijders
2024-04-15 8:15 ` Xi Ruoyao
2024-03-25 8:45 ` Andreas Schwab [this message]
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=mvm5xxahf8w.fsf@suse.de \
--to=schwab@suse.de \
--cc=fweimer@redhat.com \
--cc=job@fastly.com \
--cc=libc-alpha@sourceware.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).