setopt: avoid integer overflows when setting millsecond values #1938
Conversation
That may affect the backwards compatibility... I think we should check for negative timeout values in the code:
|
|
(weird CI failures)
You mean for application that on purpose set one of these values to a negative value? How would it otherwise affect existing apps? Since these options are documented to be time-out values, in milliseconds, my view is that we have implied that negative values are not ok. I should probably amend this commit by clarifying that in the docs for them. |
Yes. Maybe an application does not use a fixed timeout value, but calculates it in a weird way, so that it may get negative. This negative timeout should replace/disable the existing timeout. |
|
But that's asking for bug or side-effect compatibility since setting a negative timeout has never been explicitly supported. I don't think we need to be very concerned about that, at least not as long as they are mostly theoretical edge cases. |
|
One could argue that we help those wrong-doing applications by returning an error code for this case... |
bagder
force-pushed
the
bagder/setopt-ms-integer-overflows
branch
from
18e3d6d
to
4635f2e
Compare
|
Refreshed, now with updated man pages and the commit message now mentions that the max timeout time these support is slightly over 596 hours on 32 bit long systems. |
|
I think it's important that libcurl behaves in a consistent way regarding negative timeouts, so it should also reject them for |
|
Agreed! While my initial focus was to address the undefined behavior, I quite agree that inconsistency here isn't very good and also accepting bad values is also not good. I'll amend this... |
|
(I will probably try to land #1944 first, then rebase this work. To minimize the necessary conflict resolution work...) |
... that are multiplied by 1000 when stored. For 32 bit long systems, the max value accepted (2147483 seconds) is > 596 hours which is unlikely to ever be set by a legitimate application - and previously it didn't work either, it just caused undefined behavior. Also updated the man pages for these timeout options to mention the return code.
... filter early instead of risking "funny values" having to be dealt with elsewhere.
bagder
force-pushed
the
bagder/setopt-ms-integer-overflows
branch
from
4635f2e
to
14d9b4e
Compare
|
Or maybe this one first, then redo the #1944 ... |
... that are multiplied by 1000 when stored. Also ignore negative timeout values.