On 9/13/2021 7:01 AM, Daniel Stenberg via curl-library wrote: > A) If we drop the < 64 bit requirement (1), we can introduce > CURLOPT_PROTOCOLS_LARGE etc that use a (guaranteed) 64 bit type and we > double room for protocols, which should be enough for the forseeable > future. > > B) If we maintain the < 64 bit requirement (1), we would have to do > something like introducing a *second* protocol option for the next set > of protocols. It would be error-prone and cumbersome for users (it > will appear semi-random as to which protocols that appear in which > bitmask etc) and also inconvenient to handle internally. Perpaps one > of the bits in the first bitmask should then signal that there are > bits set in the second one. Or perhaps that's not necessary.
I like CURLOPT_PROTOCOLS_LARGE and I think that we could continue to support systems that do not have a 64-bit type (like what?) by not defining those proto masks for them. I think a bigger problem would be users that continue to use CURLOPT_PROTOCOLS and the like but pass those options extended protocols, effectively passing a curl_off_t to an option that expects a long. We could have a signal bit like a trouble bit in every extended protocol and then check what is passed in curlopt_protocols for the trouble bit and refuse to work in such a case. Like this #define CURLPROTO_EXTENDED_FLAG (1<<30) #define CURLPROTO_DONT_USE (1<<31) #define CURLPROTO_MAKE_EXTENDED(idx) (CURL_OFF_T_C(1)<<idx)|CURLPROTO_EXTENDED_FLAG #define CURLPROTO_IS_EXTENDED(proto) ((proto)&CURLPROTO_EXTENDED_FLAG) #define CURLPROTO_FOO CURLPROTO_MAKE_EXTENDED(32) #define CURLPROTO_BAR CURLPROTO_MAKE_EXTENDED(33) CURLPROTO_ALL could still technically enable everything and in CURLOPT_PROTOCOLS setopt: long allowed_protocols = va_arg(param, long); if((allowed_protocols&CURLPROTO_EXTENDED_FLAG) && allowed_protocols != CURLPROTO_ALL) /* problem */ -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
