apt/test/libapt/strutil_test.cc, branch 3.1.3Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=3.1.32024-11-28T09:17:21Zstrutl: Add Base64Decode2024-11-28T09:17:21ZJulian Andres Klodejak@debian.org2024-11-23T18:32:06Zurn:sha1:62cc071f88cb33c1f6213c9dbd54a10135c5ad34
Lifted from the dpkg mtree code that mjg59 submitted in
https://lists.debian.org/debian-dpkg/2018/05/msg00005.html
Which as dpkg is GPL-2.0+ also is GPL-2.0+
test/libapt/strutil_test.cc: APT::StringView -> std::string_view2024-11-12T17:18:27Zнабnabijaczleweli@nabijaczleweli.xyz2024-11-12T16:59:44Zurn:sha1:d324b6cc265b6ac3183d722cc11229e10158d960build: test: Silence warnings in GTest code2024-04-20T12:15:47ZJulian Andres Klodejulian.klode@canonical.com2024-04-20T12:09:37Zurn:sha1:4e9a9dbf9bd52d38ab5818f3eb32c8189fd25671
GTest has a lot of broken things with signed vs unsigned,
and double integer promotions, let's silence them.
Forbid negative values in unsigned StrToNum explicitly2021-02-03T16:36:46ZDavid Kalnischkiesdavid@kalnischkies.de2020-05-13T07:07:19Zurn:sha1:e0743a85c5f5f2f83d91c305450e8ba192194cd8
strtoul(l) surprises us with parsing negative values which should not
exist in the places we use to parse them, so we can just downright
refuse them rather than trying to work with them by having them promoted
to huge positive values.
Don't parse \x and \0 past the end in DeEscapeString2021-02-03T16:36:45ZDavid Kalnischkiesdavid@kalnischkies.de2020-12-03T09:44:27Zurn:sha1:ed192f410da36aedf5e54bb3f967e6613ab4bb51
This has no attack surface though as the loop is to end very soon anyhow
and the method only used while reading CD-ROM mountpoints which seems
like a very unlikely attack vector…
Fix incorrect base64 encoding due to int promotion2021-02-03T16:36:45ZDavid Kalnischkiesdavid@kalnischkies.de2020-12-03T09:41:43Zurn:sha1:10f13938bbf1474451fadcd62e1c31c4b5f5b3d7
For \xff and friends with the highest bit set and hence being a negative
value on signed char systems the wrong encoding is produced as we run
into undefined behaviour accessing negative array indexes.
We can avoid this problem simply by using an unsigned data type.
Add a simple test for APT::String::DisplayLength2021-02-03T16:36:45ZDavid Kalnischkiesdavid@kalnischkies.de2020-12-03T09:35:29Zurn:sha1:1b3ad3891465f8b72bcedfb4edd513cb74eec7f3
References: 2497198e9599a6a8d4d0ad08627bcfc7ea49c644
Gbp-Dch: Ignore
Allow prefix to be a complete filename for GetTempFile2020-05-18T13:55:36ZDavid Kalnischkiesdavid@kalnischkies.de2020-05-18T09:55:54Zurn:sha1:c470d92366d7c3c239a689f0a10d6d0d9daafbff
Our testcases had their own implementation of GetTempFile with the
feature of a temporary file with a choosen suffix. Merging this into
GetTempFile lets us drop this duplicate and hence test more our code
rather than testing our helpers for test implementation.
And then hashsums_test had another implementation… and extracttar wasn't
even trying to use a real tempfile… one GetTempFile to rule them all!
That also ensures that these tempfiles are created in a temporary
directory rather than the current directory which is a nice touch and
tries a little harder to clean up those tempfiles.
Prevent GTest from flooding us with compiler warnings2018-05-04T16:42:37ZDavid Kalnischkiesdavid@kalnischkies.de2018-05-04T16:24:57Zurn:sha1:1d77c915005f7630949e2ce706055ee3235009b6
GTest has a bunch of undefined macros which causes the compiler to spit
out warnings for each one on each test file. There isn't much we can do,
so we just disable the warning for the testcases. Other warnings like
sign-promo and sign-compare we can avoid by being more explicit about
our expected integer constants being unsigned.
As we are just changing testcases, there is no user visible change which
would deserve to be noted in the changelog.
Gbp-Dch: Ignore
Reported-By: gcc-8
support multiline values in LookupTag2017-12-13T22:56:29ZDavid Kalnischkiesdavid@kalnischkies.de2017-07-17T08:52:09Zurn:sha1:07cd99066c30e70a9f41851c80e7c51f4e507163
LookupTag is a little helper to deal with rfc822-style strings we use in
apt e.g. to pass acquire messages around for cases in which our usual
rfc822 parser is too heavy. All the fields it had to deal with so far
were single line, but if they aren't it should really produce the right
output and not just return the first line. Error messages are a prime
candidate for becoming multiline as at the moment they are stripped of
potential newlines due to the previous insufficiency of LookupTag.