For a pointer iterator used often, a single-letter identifier is more
appropriate. That reduces the length of lines considerably, avoiding
unnecessary line breaks. And since we initialize it with
m = mappings;
it's clear what it is.
Link: <ff2baed5db (r136635300)>
Cc: Serge Hallyn <serge@hallyn.com>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
Previously, we were performing the following two checks:
- if (ranges != ((argc + 2) / 3)) {
- if ((ranges * 3) > argc) {
Let's draw a table of the possible input that would pass the first check:
argc: 0 1 2 3 4 5 6 7 8 9
rng: 0 1 1 1 2 2 2 3 3 3
a+2/3*3:0 3 3 3 6 6 6 9 9 9 <-- this is roundup(argc, 3);
a+2/3: 0 1 1 1 2 2 2 3 3 3 <-- this is roundup(argc, 3) / 3;
rng*3: 0 3 3 3 6 6 6 9 9 9
From those, let's extract those that would also pass the second check:
argc: 0 3 6 9
rng: 0 1 2 3
rng*3: 0 3 6 9
We can see that there's a simple check for this input:
+ if (ranges * 3 != argc) {
As a sanity check, let's draw a table of the acceptable input with that
check:
rng: 0 1 2 3
rng*3: 0 3 6 9
argc: 0 3 6 9
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Serge Hallyn <serge@hallyn.com>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
Check for close(2) failure at more places closing a file descriptor
written to.
Also ignore failures with errno set to EINTR (see man:close(2) for
details).
It was blessed by POSIX.1-2001, and GCC says that it won't go away,
possibly ever.
memset(3) is dangerous, as the 2nd and 3rd arguments can be accidentally
swapped --who remembers what's the order of the 2nd and 3rd parameters
to memset(3) without checking the manual page or some code that uses
it?--. Some recent compilers may be able to catch that via some
warnings, but those are not infalible. And even if compiler warnings
could always catch that, the time lost in fixing or checking the docs is
lost for no clear gain. Having a sane API that is unambiguous is the
Right Thing (tm); and that API is bzero(3).
If someone doesn't believe memset(3) is error-prone, please read the
book "Unix Network Programming", Volume 1, 3rd Edition by Stevens, et
al., Section 1.2. See a stackoverflow reference in the link below[1].
bzero(3) had a bad fame in the bad old days, because some ancient
systems (I'm talking of many decades ago) shipped a broken version of
bzero(3). We can assume that all systems in which current shadow utils
can be built, have a working version of bzero(3) --if not, please fix
your broken system; don't blame the programmer--.
One reason that some use today to avoid bzero(3) in favor of memset(3)
is that memset(3) is more often used; but that's a circular reasoning.
Even if bzero(3) wasn't supported by the system, it would need to be
invented. It's the right API.
Another reason that some argue is that POSIX.1-2008 removed the
specification of bzero(3). That's not a problem, because GCC will
probably support it forever, and even if it didn't, we can redefine it
like we do with memzero(). bzero(3) is just a one-liner wrapper around
memset(3).
Link: [1] <https://stackoverflow.com/a/17097978>
Cc: Christian Göttsche <cgzones@googlemail.com>
Cc: Serge Hallyn <serge@hallyn.com>
Cc: Iker Pedrosa <ipedrosa@redhat.com>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
