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 J
We're talking APIs (*), that includes the types. So yes, that's a
safe assumption.
Cheers,
Richard
(*) if people stopped using "API" when they mean "function", that
would save the world from a pile of confusion.
On Thu, 23 Jul 2020 18:45:49 +0200,
Short, Todd wrote:
>
>
> They also corres
I think the types should change to match any function name changes.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 24 Jul 2020, at 2:45 am, Short, Todd wrote:
>
> They also correspond directly to EVP_MAC and EVP_KDF
Adherence to the code style will also be required (indentation will change).
This will be harder to automate.
Changing EVP_RAND -> OSSL_RAND is worse because it will change line breaks as
well as indentation. OSSL_RNG avoids this, if we accept not using RAND in the
name.
KDF and MAC also get
> They also correspond directly to EVP_MAC and EVP_KDF types. Would the types
> change as well?
Yes, if we would decide to change the EVP_MAC and EVP_KDF prefix, then this
would not only
apply to the functions, but to the types as well.
Matthias
They also correspond directly to EVP_MAC and EVP_KDF types. Would the types
change as well?
--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet."
> On Jul 23, 2020, at 11:56 AM, Matt Caswell wrote:
>
>
>
> On 23/07/2020 16:52, Richard Levitte wrote:
> I was thinking OSSL_LIBCTX?
That's a good choice and consistent with how we name the variable in most (but
not all) places:
OPENSSL_CTX *libctx;
I volunteer to raise a pull request which does a scripted bulk rename, as soon
as we have made
a decision. Ideally, the bulk renaming shoul
As @levitte pointed out - it was not back ported (not sure why I thought it
was)
> On 24 Jul 2020, at 5:40 pm, Dr. Matthias St. Pierre
> wrote:
>
> > I think the KDF and MAC got back ported also...
>
> In this case it would be no question that we should keep the names EVP_KDF
> and EVP_MAC
I was thinking OSSL_LIBCTX?
> On 24 Jul 2020, at 5:38 pm, Dr. Matthias St. Pierre
> 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 fea
> I think the KDF and MAC got back ported also...
In this case it would be no question that we should keep the names EVP_KDF and
EVP_MAC.
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 sta
11 matches
Mail list logo