a comma separated string would be the fully future compatible option unless 64 (long long should work for LLP64) is enough for the unknown future. The internal representation could still be a bitfield for performance reasons, but the public API should probably be a more future proof one.
/HH Den fre 10 juni 2022 kl 17:33 skrev Max Dymond via curl-library < curl-library@lists.haxx.se>: > > > If anyone has a better idea on how to solve this challenge, then let > me know! > > > Should we take the opportunity to create a replacement to > CURLOPT_PROTOCOLS and deprecate that? > > > Off the top of my head a replacement could be: > > > * A 64-bit value - I appreciate I've been out of the curl game a while > so are 64-bit options fully supported on all platforms now, for example, > are 64-bit options still a 'long' which on LLP64 platforms is an issue? > > * A structure, which might include the base protocol, whether it is TLS > or not, etc... > > Perhaps simply "a string"? > https://github.com/curl/curl/blob/master/src/tool_libinfo.c already > converts a proto name (e.g. "https", "sftp") into a value - I don't think > it's beyond the realms of feasibility to have a similar API to replace > CURLOPT_PROTOCOLS. > -- > Unsubscribe: https://lists.haxx.se/listinfo/curl-library > Etiquette: https://curl.haxx.se/mail/etiquette.html >
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
