<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/apt-pkg/contrib/mmap.cc, branch 2.3.4</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=2.3.4</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=2.3.4'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2021-02-04T10:00:00Z</updated>
<entry>
<title>Avoid undefined pointer arithmetic while growing mmap</title>
<updated>2021-02-04T10:00:00Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2020-06-08T15:07:43Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=f7e6eaf84bebac565f462e2ce48f30808cc771eb'/>
<id>urn:sha1:f7e6eaf84bebac565f462e2ce48f30808cc771eb</id>
<content type='text'>
The undefined behaviour sanitizer complains with:
runtime error: addition of unsigned offset to 0x… overflowed to 0x…

Compilers and runtime do the right thing in any case and it is a
codepath that can (and ideally should) be avoided for speed reasons
alone, but fixing it can't hurt (too much).
</content>
</entry>
<entry>
<title>mmap: Do not look for empty pool unless we need to</title>
<updated>2020-01-17T16:19:56Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2020-01-17T16:19:56Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=8dc1d3c4662e9009ed56483fd4254ee1154b6e23'/>
<id>urn:sha1:8dc1d3c4662e9009ed56483fd4254ee1154b6e23</id>
<content type='text'>
Given that we have a maximum of 12 pools, and much more
items to insert, it does not make sense to have two branches
in the hot path.

Move the search for an empty pool into the unlikely case
that no matching pool has been created yet - a condition
that is guaranteed to only happens up to 12 times.
</content>
</entry>
<entry>
<title>Remove obsolete RCS keywords</title>
<updated>2018-05-07T11:41:31Z</updated>
<author>
<name>Guillem Jover</name>
<email>guillem@debian.org</email>
</author>
<published>2018-05-06T20:32:41Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=164f1b78d1849a0f33df7352875f86e28f5de06a'/>
<id>urn:sha1:164f1b78d1849a0f33df7352875f86e28f5de06a</id>
<content type='text'>
Prompted-by: Jakub Wilk &lt;jwilk@debian.org&gt;
</content>
</entry>
<entry>
<title>convert various c-style casts to C++-style</title>
<updated>2017-12-13T22:53:34Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2017-12-13T12:26:38Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=957381a0d26ec11a172ebfc64f892d1b31f0c193'/>
<id>urn:sha1:957381a0d26ec11a172ebfc64f892d1b31f0c193</id>
<content type='text'>
gcc was warning about ignored type qualifiers for all of them due to the
last 'const', so dropping that and converting to static_cast in the
process removes the here harmless warning to avoid hidden real issues in
them later on.

Reported-By: gcc
Gbp-Dch: Ignore
</content>
</entry>
<entry>
<title>Reformat and sort all includes with clang-format</title>
<updated>2017-07-12T11:57:51Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2017-07-12T11:40:41Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=87274d0f22e1dfd99b2e5200e2fe75c1b804eac3'/>
<id>urn:sha1:87274d0f22e1dfd99b2e5200e2fe75c1b804eac3</id>
<content type='text'>
This makes it easier to see which headers includes what.

The changes were done by running

    git grep -l '#\s*include'  \
        | grep -E '.(cc|h)$' \
        | xargs sed -i -E 's/(^\s*)#(\s*)include/\1#\2 include/'

To modify all include lines by adding a space, and then running
./git-clang-format.sh.
</content>
</entry>
<entry>
<title>fix various typos reported by spellintian</title>
<updated>2017-01-19T14:59:38Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2017-01-19T14:14:19Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=93cff633a830e222693fc0f3d78e6e534d1126ee'/>
<id>urn:sha1:93cff633a830e222693fc0f3d78e6e534d1126ee</id>
<content type='text'>
Most of them in (old) code comments. The two instances of user visible
string changes the po files of the manpages are fixed up as well.

Gbp-Dch: Ignore
Reported-By: spellintian
</content>
</entry>
<entry>
<title>Store the size of strings in the cache</title>
<updated>2016-01-08T20:20:25Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-01-08T10:12:14Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=60d523e2ae93a6c5bc396b6bede2544271fb1f2e'/>
<id>urn:sha1:60d523e2ae93a6c5bc396b6bede2544271fb1f2e</id>
<content type='text'>
By storing the size of the string in the cache, we can make use of
it when comparing the names in the hashtable in pkgCache::FindGrp.
</content>
</entry>
<entry>
<title>mmap: Define _DEFAULT_SOURCE instead of _BSD_SOURCE</title>
<updated>2015-12-11T14:02:24Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2015-12-11T14:02:24Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=f9d8a91570788b676cabceede3229860ad76734e'/>
<id>urn:sha1:f9d8a91570788b676cabceede3229860ad76734e</id>
<content type='text'>
Fixes a warning reported by gcc.

Gbp-Dch: ignore
</content>
</entry>
<entry>
<title>do not segfault in cache generation on mmap failure</title>
<updated>2015-11-19T23:54:07Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-11-19T23:54:07Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=6789e01e9370b3b7f65d52138c5657eaa712b4d1'/>
<id>urn:sha1:6789e01e9370b3b7f65d52138c5657eaa712b4d1</id>
<content type='text'>
Out of memory and similar circumstanzas could cause MMap::Map to fail
and especially the mmap/malloc calls in it. With some additional
checking we can avoid segfaults and similar in such situations – at
least in theory as if this is a real out of memory everything we do to
handle the error could just as well run into a memory problem as well…

But at least in theory (if MMap::Map is made to fail always) we can deal
with it so good that a user actually never sees a failure (as the cache
it tries to load with it fails and is discarded, so that DynamicMMap
takes over and a new one is build) instead of segfaulting.

Closes: 803417
</content>
</entry>
<entry>
<title>avoid using global PendingError to avoid failing too often too soon</title>
<updated>2015-09-14T13:22:18Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-09-10T17:00:51Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=95278287f4e1eeaf5d96749d6fc9bfc53fb400d0'/>
<id>urn:sha1:95278287f4e1eeaf5d96749d6fc9bfc53fb400d0</id>
<content type='text'>
Our error reporting is historically grown into some kind of mess.
A while ago I implemented stacking for the global error which is used in
this commit now to wrap calls to functions which do not report (all)
errors via return, so that only failures in those calls cause a failure
to propergate down the chain rather than failing if anything
(potentially totally unrelated) has failed at some point in the past.

This way we can avoid stopping the entire acquire process just because a
single source produced an error for example. It also means that after
the acquire process the cache is generated – even if the acquire
process had failures – as we still have the old good data around we can and
should generate a cache for (again).

There are probably more instances of this hiding, but all these looked
like the easiest to work with and fix with reasonable (aka net-positive)
effects.
</content>
</entry>
</feed>
