llvm-project.git/llvm/lib/Support/TarWriter.cpp, branch users/nico/python-2

Reland D78945 TarWriter: Only use 137 of the 155 prefix bytes.

2020-04-27T17:37:23+00:00

With a fix to unittests/Support/TarWriterTest.cpp

This makes lld's --reproduce output more compatible with tar 1.13 and
before.  This is a very old version of tar, but it's the version in
both gnuwin and unxutils, and the cost for supporting them are very
low, so we might as well just do that.

https://bugs.chromium.org/p/chromium/issues/detail?id=1073524#c21
and onward has more details.

Differential Revision: https://reviews.llvm.org/D78945

Revert "TarWriter: Only use 137 of the 155 prefix bytes."

2020-04-27T17:34:04+00:00

This reverts commit 90d6ed144c1352e393556a799e79da6ec3a5fab9.
Breaks check-llvm. Revert while I investigate.

TarWriter: Only use 137 of the 155 prefix bytes.

2020-04-27T17:15:22+00:00

This makes lld's --reproduce output more compatible with tar 1.13 and
before.  This is a very old version of tar, but it's the version in
both gnuwin and unxutils, and the cost for supporting them are very
low, so we might as well just do that.

https://bugs.chromium.org/p/chromium/issues/detail?id=1073524#c21
and onward has more details.

Differential Revision: https://reviews.llvm.org/D78945

Make llvm::StringRef to std::string conversions explicit.

2020-01-28T22:25:25+00:00

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.

Update the file headers across all of the LLVM projects in the monorepo

2019-01-19T08:50:56+00:00

to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

[FileSystem] Split up the OpenFlags enumeration.

2018-06-07T19:58:58+00:00

This breaks the OpenFlags enumeration into two separate
enumerations: OpenFlags and CreationDisposition.  The first
controls the behavior of the API depending on whether or not
the target file already exists, and is not a flags-based
enum.  The second controls more flags-like values.

This yields a more easy to understand API, while also allowing
flags to be passed to the openForRead api, where most of the
values didn't make sense before.  This also makes the apis more
testable as it becomes easy to enumerate all the configurations
which make sense, so I've added many new tests to exercise all
the different values.

llvm-svn: 334221

[Support/TarWriter] - Don't allow TarWriter to add the same file more than once.

2017-12-05T10:09:59+00:00

This is for PR35460.

Currently when LLD adds files to TarWriter it may pass the same file
multiple times. For example it happens for clang reproduce file which specifies
archive (.a) files more than once in command line. 
Patch makes TarWriter to ignore files with the same path, so it will
add only the first one to archive.

Differential revision: https://reviews.llvm.org/D40606

llvm-svn: 319750

Fix a UBsan bot.

2017-09-28T00:27:39+00:00

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.

llvm-svn: 314368

Fix off-by-one error in TarWriter.

2017-09-27T21:38:02+00:00

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

llvm-svn: 314349

TarWriter: Fix a bug in Ustar header.

2017-01-09T22:55:00+00:00

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.

llvm-svn: 291494