Why? Just because some of us used such variable names when there was a need to distinguish it from other contexts that are sometimes juggled with at the time time?
(and yeah, I've made that a habit... but why that would determine the type name, I cannot understand) Cheers, Richard On Fri, 24 Jul 2020 09:42:59 +0200, SHANE LONTIS wrote: > > I was thinking OSSL_LIBCTX? > > > On 24 Jul 2020, at 5:38 pm, Dr. Matthias St. Pierre > > <matthias.st.pie...@ncp-e.com> wrote: > > > > I like the OSSL_ prefix for new APIs as proposed by Richard. And I agree > > with Shane > > that we should go for a single prefix and not have two alternatives. > > Existing prefixes > > for things like feature macros should remain as they are, but if the OSSL_ > > prefix is > > our choice for the future, we should start using it consistently for _all_ > > new APIs in 3.0. > > And not make it a random choice (pun intended) depending on whether the API > > went > > into master early or late. So my favorite choice is a consistent renaming, > > i.e. > > > > OSSL_MAC, OSSL_KDF, OSSL_RAND, OSSL_CTX, ... > > > > OTOH, it would be ok for me if we would make an exception for EVP_MAC and > > EVP_KDF, > > because they have a long EVP history, as Matt pointed out. But using the > > EVP_ prefix > > for the new RAND interface never made sense to me. > > > > What bothers me about OPENSSL_CTX in particular is the fact that it is a > > mixture of > > a non-abbreviated and an abbreviated word. IMHO it should be either > > OSSL_CTX or > > OPENSSL_CONTEXT, and the former is obviously preferrable for its length. > > > > Matthias > > > > > >> -----Original Message----- > >> From: openssl-project <openssl-project-boun...@openssl.org> On Behalf Of > >> Richard Levitte > >> Sent: Friday, July 24, 2020 8:34 AM > >> To: openssl-project@openssl.org > >> Subject: Re: API renaming > >> > >> I'm fine with that, really. > >> > >> I have a preference for OSSL_, but if we look through the source, > >> there's reason for either. So far, we've majorly used OPENSSL_ for > >> things like feature macros (disabling macros, really), environment > >> variables, that sort of thing, while OSSL_ has become the primary > >> choice for new APIs ("less klunky", I think the judgement was in that > >> past discussion I keep referring to). > >> > >> And yeah, I hear you from all the way around the planet, there are > >> some recent name choice that were made that give pause and are > >> arguably a mistake in this regard. EVP_MAC and EVP_KDF could have > >> been OSSL_MAC and OSSL_KDF. OPENSSL_CTX could have been OSSL_CTX. > >> I have no problem recognising that. But, they are there, even though > >> only in master (*). This is question of what we do going forward (a > >> yet unmerged PR with a new API is as good a target as any). > >> > >> Cheers, > >> Richard > >> > >> (*) I'm not sure I see master as something untouchable in this regard, > >> as the development is still not frozen (alpha), so I for one could > >> easily see a rename fest happening, should we decide for it. That > >> must happen before we enter the beta phase, though... > >> > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/