curl.h: change some enums to defines with L suffix #16482
Conversation
|
Analysis of PR #16482 at d21c4f66: Test 503 failed, which has NOT been flaky recently, so there could be a real issue in this PR. Generated by Testclutch |
|
@vszakats look, I figured out some of the mysterious RTSP failures on macOS gcc-12. What's curious is that they only failed these particular builds... |
Wow, that's super nice! Those were puzzling. (edit: Ref: item 15 in c349bd6 #14097) I wonder if there is any way to make these fall out early somehow. |
To help applications do the right thing easier, change some enum values into defines with L suffixes so that they get the corect type (long) easier when used with curl_easy_setopt(). This also fixes a few of our own libtests. To reduce the risk that this change breaks the compile for any existing users, the previously provided enums are still provided, but the values to use are not defined by the enums. Closes #16482
bagder
force-pushed
the
bagder/public-enum-define
branch
from
b54099b to
9ea40e7
Compare
I think it's unnecessary to keep the enums around. When would someone be using the enum type? In C++ ? They'd already have to change it for the other symbols then wouldn't they? |
I figured this was the most conservative approach. The curl tool itself actually uses one of them and I took that as a hint that maybe there are a few other users too out there in the world who do. And keeping them is a small cost I think. If it helps not breaking a few builds out there. |
It seems reasonable to presume that they are/were. I mean this was just a plain bug in our tests that pass in ints where longs should be used. |
To help applications doing the right thing easier, change some enum values into defines with L suffixes so that they get the corect type easier when used with curl_easy_setopt().
To reduce the risk that this breaks the compile for any existing user, the previously provided enums are still provided, but the values to use are not defined by the enums.