Matt Caswell <matt@xxxxxxxxxxx> skrev: (4 mars 2019 12:59:26 CET) > > >On 01/03/2019 22:26, Paul Smith wrote: >> Hi all. >> >> I'm reading with interest the details coming out with respect to the >> next release of OpenSSL. >> >> I'm curious if there's any consideration being given to updating the >> API for existing interfaces, and/or checking the APIs of any new >> interfaces for issues that are seen in the current API. >> >> I'm talking about things like: >> >> * Const-correctness for arguments > >const correctness is an ongoing thing. I'd welcome PRs that address >this. Incidentally, I looked at clang-tidy today. It seems to have some helpful options for this kind of work. > >> * Signed vs. unsigned values for integer values > >We did do quite a bit of work internally in libssl to implement more >consistent >use of size_t where appropriate. We need to do something similar in >libcrypto >although that's probably a much bigger job. Dealing with things >internally is >much easier than changing the API - because that is obviously a >breaking change >which we try to avoid where possible. > >> * Avoiding non-portable types in the API (the most obvious example: >> using "int" as the type for socket descriptors, which is only >> portable to Windows due to an implementation detail). > >I would hope that we're not introducing any new instances of this. Any >that we >have are likely to be historical. Removing such instances would be a >matter of >deprecating the relevant APIs and making sure they have suitable >portable >replacements in place. > >> * Possibly using something like uint8_t* for pointers to buffers >> containing binary "stuff" (this could be more annoying than >helpful, >> requiring a lot of casting, so I'm not sure about that). >> >> Just wondering... seems like a good time to think about cleanups like >> that, if feasible. >> > > > >On 02/03/2019 09:18, Angus Robertson - Magenta Systems Ltd wrote: >> Also replacing all C macros such as those for SSL_CTX_ctrl with >proper >> external functions. >> >> This will ease use of OpenSSL with languages other than C, where we >> currently have to code functions to replace the macros. >> >> Google did this when creating BoringSSL, there may be other similar >> 'improvements' that could help OpenSSL. > >I'd be in favour of that for SSL_ctrl/SSL_CTX_ctrl where I don't think >the >"ctrl" pattern adds much value. All SSL_METHOD implementations share >the same >ctrl implementation, with the exception of DTLS which adds a few extra >ctrls. > >For other areas that may not be the case. For example with BIO_ctrl all >the >different BIO_METHODs all have quite separate ctrl implementations so >there >seems a bigger benefit to this pattern there. > > >Matt -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
