apt/apt-pkg/install-progress.cc, branch 2.7.12Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=2.7.122024-02-20T12:49:04ZModernize standard library includes2024-02-20T12:49:04ZJulian Andres Klodejulian.klode@canonical.com2024-02-20T12:43:08Zurn:sha1:40a75722c43ae24cb9a99d6730a3b25b65819c49
This was automated with sed and git-clang-format, and then I had to
fix up the top of policy.cc by hand as git-clang-format accidentally
indented it by two spaces.
Avoid triggering unused parameter warning in staticSIGWINCH2023-01-29T11:20:53ZDavid Kalnischkiesdavid@kalnischkies.de2022-08-31T14:03:00Zurn:sha1:136f3829940ad4bc8361085645f18795f34c905c
Reported-By: gcc -Wunused-parameter
Gbp-Dch: Ignore
Fix incorrect SIGWINCH handling2021-12-19T08:24:47ZZhang Boyangzhangboyang.id@gmail.com2021-12-01T16:21:48Zurn:sha1:ec27853181d898f738ad20fed00f37a00d1d09c3
Previously, status line is redrawn in signal handler. However, the
drawing code make heavy use of std::string and other syscalls, which may
not be async-signal-safe. This will cause deadlock, overwritten errno,
even silent memory corruption.
This patch implemented Anders Kaseorg's idea. The signal handler will
only set a flag, which is async-signal-safe, and actual redrawing will
be deferred to PackageManagerFancy::Pulse().
Note that the virtual function PackageManagerFancy::Pulse() already
exists in base class but newly overridden in PackageManagerFancy, so the
ABI compatibility should be OK. However, existing compiled programs may
not aware of this new function and continue to use old Pulse() if
compiler had done heavy optimization. Fortunately this is not too
harmful because this will only cause status line not redrawing, which
may consider acceptable.
Closes: #852757
Fix progress bar width for multibyte charsets2019-11-25T16:03:10ZАлексей Шилинrootlexx@mail.ru2019-11-22T22:04:45Zurn:sha1:2497198e9599a6a8d4d0ad08627bcfc7ea49c644
When using locale in which symbols occupy more than 1 byte (for example,
ru_RU.UTF-8), the progress bar width was calculated incorrectly because
std::string::size() returns the number of bytes rather than the number of
actual characters. Use the newly introduced APT::String::DisplayLength()
to calculate the width instead.
Avoid implicitly promotion of float to double2018-05-04T22:34:22ZDavid Kalnischkiesdavid@kalnischkies.de2018-05-04T17:02:23Zurn:sha1:5f9c05db78926dfb063fdd0493ecc6b8e12c2e02
Reported-By: gcc -Wdouble-promotion
Gbp-Dch: Ignore
remove pointless APT_PURE from void functions2017-12-14T20:55:34ZDavid Kalnischkiesdavid@kalnischkies.de2017-12-14T20:44:40Zurn:sha1:a6c7b262212d56a4ad37e6475f96152296ab1d0c
Earlier gcc versions used to complain that you should add them althrough
there isn't a lot of point to it if you think about it, but now gcc (>= 8)
complains about the attribute being present.
warning: ‘pure’ attribute on function returning ‘void’ [-Wattributes]
Reported-By: gcc -Wattributes
Gbp-Dch: Ignore
deal with floats without old-style cast2017-12-13T22:53:48ZDavid Kalnischkiesdavid@kalnischkies.de2017-12-13T20:51:52Zurn:sha1:0b5e329a8ba2461ccb7017d3adfc972f9dccd830
We have no speed problem with handling floats/doubles in our progress
handling, but that shouldn't prevent us from cleaning up the handling
slightly to avoid unclean casting to ints.
Reported-By: gcc -Wdouble-promotion -Wold-style-cast
Replace APT_CONST with APT_PURE everywhere2017-08-24T14:56:52ZJulian Andres Klodejak@debian.org2017-08-24T14:55:15Zurn:sha1:0e4ac8334d02ea256f750ad61689f28ff1ebdf6c
As a follow up to the last commit, let's replace APT_CONST
with APT_PURE everywhere to clean stuff up.
Reformat and sort all includes with clang-format2017-07-12T11:57:51ZJulian Andres Klodejak@debian.org2017-07-12T11:40:41Zurn:sha1:87274d0f22e1dfd99b2e5200e2fe75c1b804eac3
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.
Use C locale instead of C.UTF-8 for protocol strings2016-08-26T20:17:13ZJulian Andres Klodejak@debian.org2016-08-23T18:19:11Zurn:sha1:0fb16c3e678044d6d06ba8a6199b1e96487ee0d8
The C.UTF-8 locale is not portable, so we need to use C, otherwise
we crash on other systems. We can use std::locale::classic() for
that, which might also be a bit cheaper than using locale("C").