If we do not initialize Prefix here, Prefix.data() returns a nullptr.
Later, it is passed to memcpy. memcpy's behavior is undefined if src (or
dst) is a nullptr even if a given size is 0. That's why this code
triggered UBsan.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@314368 91177308-0d34-0410-b5e6-96231b3b80d8
The tar format originally supported up to 99 byte filename. The two
extensions are proposed later: Ustar or PAX.
In the UStar extension, a pathanme is split at a '/' and its "prefix"
and "suffix" are stored in different locations in the tar header. Since
"prefix" can be up to 155 byte, it can represent up to 254 byte
filename (but exact limit depends on the location of '/' character in
a pathname.)
Our TarWriter first attempt to use UStar extension and then fallback to
PAX extension.
But there's a bug in UStar header creation. "Suffix" part must be a NUL-
terminated string, but we didn't handle it correctly. As a result, if
your filename just 100 characters long, the last character was droppped.
This patch fixes the issue.
Differential Revision: https://reviews.llvm.org/D38149
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@314349 91177308-0d34-0410-b5e6-96231b3b80d8
If we split a filename into `Name` and `Prefix`, `Prefix` is at most
145 bytes. We had a bug that didn't split a path correctly. This bug
was pointed out by Rafael in the post commit review.
This patch adds a unit test for TarWriter to verify the fix.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291494 91177308-0d34-0410-b5e6-96231b3b80d8
Most (maybe all?) tar commands can handle tar archives with blank
version fields, but POSIX requires "00" to be set to the field, so
doing it is good for compliance.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291479 91177308-0d34-0410-b5e6-96231b3b80d8
Tar's Ustar header has the "prefix" field to store a directory
part of a filename. It is not as flexible as the PAX-extended
filename because there's still a limitation on the maximum filename
size, but it mitigates the situation.
This patch should unbreak some Windows buildbots that uses very
old tar command.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291340 91177308-0d34-0410-b5e6-96231b3b80d8
This usage of strcpy and snprintf was certainly safe, but using them
sets off various deprecation and lint warnings. Easier to just write the
belt and suspenders version.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291256 91177308-0d34-0410-b5e6-96231b3b80d8
We use PAX headers to store long filenames (>= 100 bytes).
It is not needed to emit PAX headers if filenames fit in the
Ustar header. This patch implements that optimization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291215 91177308-0d34-0410-b5e6-96231b3b80d8
In LLD, we create cpio archive files for --reproduce command.
cpio was not a bad choice because it is very easy to create, but
it was sometimes hard to use because people are not familiar with
cpio command.
I noticed that creating a tar archive isn't as hard as I thought.
So I implemented it in this patch.
Differential Revision: https://reviews.llvm.org/D28091
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291209 91177308-0d34-0410-b5e6-96231b3b80d8
