| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
and compiler warnings for data conversions.
Reported-by: Michał Antoniak
Fixes #7645
Closes #7653
|
|
|
|
|
|
|
| |
lib/progress.c:380:40: warning: conversion to 'long double' from
'curl_off_t {aka long long int}' may alter its value [-Wconversion]
Closes #7549
|
|
|
|
|
|
|
|
|
|
| |
Otherwise the old value would linger from a previous use and would mess
up the network speed cap logic.
Reported-by: Ymir1711 on github
Fixes #7042
Closes #7043
|
|
|
|
| |
The function becomes easier to read and understand with less repetition.
|
| |
|
|
|
|
|
|
|
|
| |
This silences two scan-build-11 warnings: "The result of the '/'
expression is undefined"
Bug: https://curl.se/mail/lib-2021-05/0022.html
Closes #7035
|
|
|
|
|
|
|
|
|
| |
... this improves precision, especially for transfers in the few or even
sub millisecond range.
Reported-by: J. Bromley
Fixes #7017
Closes #7020
|
|
|
|
|
| |
... as we know the value cannot be set to negative: enforced by
setopt()
|
|
|
|
|
|
|
| |
Make the code consistently use a single name for the size of the
"curl_off_t" type.
Closes #6702
|
|
|
|
| |
Closes #6479
|
|
|
|
|
|
|
|
|
|
| |
By setting the speed limit time stamps unconditionally at transfer
start, we can start off a transfer without speed limits and yet allow
them to get set during transfer and have an effect.
Reported-by: Kael1117 on github
Fixes #6162
Closes #6184
|
|
|
|
| |
Closes #6172
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Setting a timeout to INT_MAX could cause an immediate error to get
returned as timeout because of an overflow when different values of
'now' were used.
This is primarily fixed by having Curl_pgrsTime() return the "now" when
TIMER_STARTSINGLE is set so that the parent function will continue using
that time.
Reported-by: Ionuț-Francisc Oancea
Fixes #5583
Closes #5847
|
|
|
|
|
|
|
| |
For millisecond timers we like timediff_t better. Also, time_t can be
unsigned so returning a negative value doesn't work then.
Closes #5479
|
|
|
|
|
|
|
|
|
| |
(also for PROGRESSFUNCTION)
By returning this value from the callback, the internal progress
function call is still called afterward.
Closes #4599
|
|
|
|
|
|
|
| |
... to make it hold microseconds too.
Fixes #4165
Closes #4168
|
|
|
|
|
|
|
|
|
|
| |
... to make CURLOPT_MAX_RECV_SPEED_LARGE and
CURLOPT_MAX_SEND_SPEED_LARGE work correctly on subsequent transfers that
reuse the same handle.
Fixed-by: Ironbars13 on github
Fixes #4084
Closes #4161
|
|
|
|
|
|
|
|
| |
Fix regression caused by 21080e1
Reported-by: Chih-Hsuan Yen
Fixes #4122
Closes #4124
|
|
|
|
|
|
| |
Builds libcurl without support for the built-in progress meter.
Closes #4023
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 3b06e68b7734cb10a555f9d7e804dd5d808236a4.
Clearly this change wasn't good enough as it broke CURLOPT_LOW_SPEED_LIMIT +
CURLOPT_LOW_SPEED_TIME
Reported-by: Dave Reisner
Fixes #3927
Closes #3928
|
| |
|
|
|
|
|
|
|
| |
Codacy/CppCheck warns about this. Consistently use parentheses as we
already do in some places to silence the warning.
Closes https://github.com/curl/curl/pull/3866
|
|
|
|
|
|
|
|
|
|
|
| |
The function does not return the same value as snprintf() normally does,
so readers may be mislead into thinking the code works differently than
it actually does. A different function name makes this easier to detect.
Reported-by: Tomas Hoger
Assisted-by: Daniel Gustafsson
Fixes #3296
Closes #3297
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Get rid of variable that was generating false positive warning
(unitialized)
- Fix issues in tests
- Reduce scope of several variables all over
etc
Closes #2631
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to very frequent updates of the rate limit "window", it could
attempt to rate limit within the same milliseconds and that then made
the calculations wrong, leading to it not behaving correctly on very
fast transfers.
This new logic updates the rate limit "window" to be no shorter than the
last three seconds and only updating the timestamps for this when
switching between the states TOOFAST/PERFORM.
Reported-by: 刘佩东
Fixes #2386
Closes #2388
|
|
|
|
| |
follow-up to 72a0f62
|
|
|
|
|
|
|
|
| |
... and make sure to avoid integer overflows with really large values.
Reported-by: 刘佩东
Fixes #2371
Closes #2373
|
|
|
|
| |
Closes #2302
|
|
|
|
|
|
|
| |
to increase accuracy for quick transfers
Fixes #2200
Closes #2206
|
|
|
|
|
|
|
|
|
|
| |
... since the 'tv' stood for timeval and this function does not return a
timeval struct anymore.
Also, cleaned up the Curl_timediff*() functions to avoid typecasts and
clean up the descriptive comments.
Closes #2011
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... to cater for systems with unsigned time_t variables.
- Renamed the functions to curlx_timediff and Curl_timediff_us.
- Added overflow protection for both of them in either direction for
both 32 bit and 64 bit time_ts
- Reprefixed the curlx_time functions to use Curl_*
Reported-by: Peter Piekarski
Fixes #2004
Closes #2005
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update the progress timers `t_nslookup`, `t_connect`, `t_appconnect`,
`t_pretransfer`, and `t_starttransfer` to track the total times for
these activities when a redirect is followed. Previously, only the times
for the most recent request would be tracked.
Related changes:
- Rename `Curl_pgrsResetTimesSizes` to `Curl_pgrsResetTransferSizes`
now that the function only resets transfer sizes and no longer
modifies any of the progress timers.
- Add a bool to the `Progress` struct that is used to prevent
double-counting `t_starttransfer` times.
Added test case 1399.
Fixes #522 and Known Bug 1.8
Closes #1602
Reported-by: joshhe on github
|
|
|
|
|
|
|
|
|
| |
... to make all libcurl internals able to use the same data types for
the struct members. The timeval struct differs subtly on several
platforms so it makes it cumbersome to use everywhere.
Ref: #1652
Closes #1693
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prevent `Curl_pgrsTime` from modifying `t_starttransfer` when invoked
with `TIMER_STARTTRANSFER` more than once during a single request.
When a redirect occurs, this is considered a new request and
`t_starttransfer` can be updated to reflect the `t_starttransfer` time
of the redirect request.
Closes #1616
Bug: https://github.com/curl/curl/pull/1602#issuecomment-310267370
|
|
|
|
| |
follow-up to 64ed44a815e4e to fix test 500 failures
|
| |
|
|
|
|
|
|
| |
Bug #1556
Reported-by: Paul Harris
Closes #1559
|
|
|
|
|
|
|
|
|
|
|
|
| |
This gives us accurate precision and it allows us to avoid storing "no
time" for systems with too low timer resolution as we then bump the time
up to 1 microsecond. Should fix test 573 on windows.
Remove the now unused curlx_tvdiff_secs() function.
Maintains the external getinfo() API with using doubles.
Fixes #1531
|
|
|
|
| |
Closes #1356
|
|
|
|
|
|
| |
... by removing the else branch after a return, break or continue.
Closes #1310
|
|
|
|
|
|
| |
Blah, I accidentally wrote size_t instead of time_t for two variables.
Reported-by: Dave Reisner
|
|
|
|
|
| |
... as long is still 32bit on modern 64bit windows machines, while
time_t is generally 64bit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Speed limits (from CURLOPT_MAX_RECV_SPEED_LARGE &
CURLOPT_MAX_SEND_SPEED_LARGE) were applied simply by comparing limits
with the cumulative average speed of the entire transfer; While this
might work at times with good/constant connections, in other cases it
can result to the limits simply being "ignored" for more than "short
bursts" (as told in man page).
Consider a download that goes on much slower than the limit for some
time (because bandwidth is used elsewhere, server is slow, whatever the
reason), then once things get better, curl would simply ignore the limit
up until the average speed (since the beginning of the transfer) reached
the limit. This could prove the limit useless to effectively avoid
using the entire bandwidth (at least for quite some time).
So instead, we now use a "moving starting point" as reference, and every
time at least as much as the limit as been transferred, we can reset
this starting point to the current position. This gets a good limiting
effect that applies to the "current speed" with instant reactivity (in
case of sudden speed burst).
Closes #971
|
| |
|
| |
|
|
|
|
|
| |
... and as a consequence, introduce curl_printf.h with that re-define
magic instead and make all libcurl code use that instead.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Historically the default "unknown" value for progress.size_dl and
progress.size_ul has been zero, since these values are initialized
implicitly by the calloc that allocates the curl handle that these
variables are a part of. Users of curl that install progress
callbacks may expect these values to always be >= 0.
Currently it is possible for progress.size_dl and progress.size_ul
to by set to a value of -1, if Curl_pgrsSetDownloadSize() or
Curl_pgrsSetUploadSize() are passed a "size" of -1 (which a few
places currently do, and a following patch will add more). So
lets update Curl_pgrsSetDownloadSize() and Curl_pgrsSetUploadSize()
so they make sure that these variables always contain a value that
is >= 0.
Updates test579 and test599.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In commit 0b3750b5c23c25f (released in 7.36.0) we fixed a timeout issue
but instead broke the timings.
To fix this, I introduce a new timestamp to use for the timeouts and
restored the previous timestamp and timestamp position so that the old
timer functionality is restored.
In addition to that, that change also broke connection timeouts for when
more than one connect was used (as it would then count the total time
from the first connect and not for the most recent one). Now
Curl_timeleft() has been modified so that it checks against different
start times depending on which timeout it checks.
Test 1303 is updated accordingly.
Bug: http://curl.haxx.se/mail/lib-2014-05/0147.html
Reported-by: Ryan Braud
|