In the description of 3111908b03, it says
that the functions must be able to handle st being NULL, but recurse
always passes a valid pointer. The only function that was ever passed
NULL was rm(), but this was changed to go through recurse in
2f4ab52739, so now the checks are
pointless.
In commit 30fd43d7f3, unescape was
simplified significantly, but the new version failed to NULL terminate
the resulting string.
This causes bad behavior in various utilities, for example tr:
Broken:
$ echo b2 | tr '\142' '\143'
c3
Fixed:
$ echo b2 | tr '\142' '\143'
c2
This bug breaks libtool's usage of tr, causing gcc to fail to build with
sbase.
Function declarators with empty parentheses is an obsolescent feature in
C99, and it is not clear to me that the standard allows assigning
assigning a function pointer declared in this way to a function declared
in prototype-format.
In any case, using a union for the functions is just as simple and
enforces that we pass the correct types to the functions.
From 6665eaa1d2c25a95b44a4f4fb3d24a3bd5c1180f Mon Sep 17 00:00:00 2001
From: Thomas Mannay <audiobarrier@openmailbox.org>
Date: Thu, 3 Nov 2016 15:16:32 +0000
Subject: [PATCH] Treat addresses of 0 as 1 for insert
_Bug_
Got the following error after cloning and running make:
paste.c: In function ‘parallel’:
paste.c:70:4: warning: this ‘else’ clause does not guard... [-Wmisleading-indentation]
else
^~~~
paste.c:72:5: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘else’
last++;
^~~~
This patch preserves the same functionality and just adjusts indentation to squelch the warning.
_Test plan_
Used the following 'script' to convince myself output looked correct for inputs
where the latter arguments to paste had fewer lines.
make && printf "1\n2\n" > two.txt && printf "" > zero.txt && ./paste -d, two.txt zero.txt
Previously, if a file failed to read in a checksum list, it would be
reported as not matched rather than a read failure.
Also, if reading from stdin failed, previously a bogus checksum would be
printed anyway.
The -s flag previously called strip(1) on the installed file.
This patch changes install(1)'s behaviour to ignore -s.
Many makefiles use the -s flag, so it has to be recognised for
compatibility, however it does not have to do anything because
symbols do not negatively affect the functionallity of binaries.
Ignoring -s have the added benefit that the user do not need
to edit makefiles if they want the symbols that are useful for
debugging. If the user wants to strip away symbols, it can be
done manually or automatically by the package manager.
Laslo: Update the man-date and remove -s from usage()
Signed-off-by: Mattias Andrée <maandree@kth.se>
memmove moves a number of bytes, not pointers, so if you passed a number
of arguments that is larger than the pointer byte size, you could
end up crashing or skipping the install of a file and installing another
twice.
Also, argv was never decreased to match the moved arguments, so the -t
parameter was added in the NULL argv slot.
Also, since parsemode exits on failure, don't bother checking return
value in xinstall (this would never trigger anyway because mode_t can be
unsigned).
The %b case was using fputs after unescape to print the argument, which
meant that it could not handle nul bytes. Instead, store the length
returned from unescape and use fwrite to properly handle them.
Laslo: Fix some things pointed out by mandoc -Tlint:
1) replace empty lines with .Pp, we want to start a new
paragraph
2) Add a comma before the second item in SEE ALSO
3) Place SEE ALSO before STANDARDS, as is the convention
4) Update the man-date
By stripping backslashes this code caused a number of bugs.
'\<digit>' expressions caused literal <digit>s to be subbed-in,
'\&' was treated identically to '&', and other escaped characters
added garbage to the string.
regexec(3) happily matches /^$/ against the text of line
zero (the null string), causing an error.
Also update email address for Wolfgang Corcoran-Mathe
See his description below. Thanks Michael!
---
A bug was introduced in bc4c293fe5 causing the
range length for the next set to be used instead of the first one. This causes
issues when choosing the replacement rune when the ranges are of different
lengths.
Current behavior:
$ echo 1234 | tr 'a-f1-4' '1-6a-d'
56ab
Correct behavior:
$ echo 1234 | tr 'a-f1-4' '1-6a-d'
abcd
This also fixes range expressions in the form [a-z], which get encoded as four
ranges '[', 'a'..'z', ']', causing all a-z characters to get mapped to ']'. This
form is occasionally used in shell scripts, including the syscalltbl.sh script
used to build linux.
---
Previously, this would not work properly and not be let through the
sanity check.
This is a dirty hack until the next iteration where I'll clean up the
data structures and make this saner.
If you look at GNU coreutils, they do not support the mappings
$ echo "1234abc" | tr "[:alnum:]" "[:upper:]"
$ echo "ABCabc" | tr -c "[:upper:]" "[l*]"
to only give a few examples. This commit broadens the scope of tr(1)
as far as humanly possible to map between classes and non-classes,
making tr a usable tool and actually fulfilling user expectations.
Posix really is of no help here as it still kind of assumes the
fixed ASCII table instead of complex Unicode code points or even
Grapheme clusters.
Okay, it took me a while and another look at the Posix spec to see that
I have been dealing with squeezing in a way too complicated way.
What just needed to be done is before doing the final write to deploy
the squeeze-check. We actually do not need this atomically complicated
squeeze check in every single edge-case. Now it should work properly.
