On 03/05, Gisle Vanem wrote:
Yes, it was an off-by-one error but not where you thought. The assert statement itself was off by one. I wanted to check that there is no issue in computing the progress bar's width. A padding of size zero at the end of the progress bar is perfectly acceptable but my assert statement didn't allow for it. I've pushed a change that fixes this issue.Darshit (?), the progress.c change to add the assert() at line 1167: assert (padding > 0 && "Padding length became non-positive!");always triggers on MSVC-2015 and TDM-gcc (w/o -DNDEBUG). Not sure it's because of 'determine_screen_width()', 'USE_NLS_PROGRESS_BAR=1' or something else, but a: assert (padding >= 0 && "Padding length became non-positive!"); fixes it. Some off-by-1 calculation?
However, one a slight side note, we do need better CI tests for Windows. @Gisle, would it be possible for you to write a build rule for Wget on AppVeyor? I've tried, but lacking a Windows machine, writing those build scripts is pretty hard. AppVeyor provides a free Windows CI testing service.
BTW, here is what it looks like on Win-10 (120 x 50 screen): http://watt-32.net/misc/wget-progress-1.png (default --progress=bar) http://watt-32.net/misc/wget-progress-2.png (-q --show-progress) with a modified patch of Jernej Simončič Windows TaskBar feature: https://eternallybored.org/misc/wget/src/taskbar-progress.patch -- --gv
-- Thanking You, Darshit Shah
signature.asc
Description: PGP signature
