Can you provide a plausible rationale for these? The provider context is allocated in the "new" callback and a non-null value is passed to all the other methods by the EVP layer, I am not aware of any opportunities for a NULL value in the vctx.

Why "back"? I can't find any commit that removed them, they seem to be absent from the commits the added the respective KDFs.

These checks were added in the various recent generated decoder PRs I done. The PR removing them (#28176) was merged yesterday. Before they were added, it was a hodgepodge where some implementations did these checks and some didn't. The decoder work changed them all to include the check because this was specifically requested by a reviewer of some of the initial effort. Now that a few checks have been removed, we're back to a less than ideal inconsistent state.

The rationale is that these are a public API and we make an effort to check arguments in public APIs. I know that libcrypto does the right thing and never passes nulls to providers but that doesn't mean other callers will be so diligent. I'm aware of several providers that directly call other providers without involving libcrypto:

• We've got one in our test suite.
• There was work towards a load balancing provider a while back.
• A proxy provider was being done.
• The DRBGs directly call their parents for various things.

There is also nothing stopping an application from calling providers directly: the APIs in question are public and stable after all. Hyrum’s law is almost certainly in effect.

I've raised an issue (#28202) to have a committer discussion about this. We either want them everywhere or nowhere. I don't much care which but we need to choose one way or the other and make all of the required changes. This PR represents the easier path.

I see, thank you for the explanation. As these are public API, I'd suggest to expressly annotate the relevant arguments with __attribute__((nonnull)), both in function definitions/declarations and the callback fields definitions, if they are expected to be non-NULL, or indeed put back these checks otherwise.

I see, thank you for the explanation. As these are public API, I'd suggest to expressly annotate the relevant arguments with __attribute__((nonnull)), both in function definitions/declarations and the callback fields definitions, if they are expected to be non-NULL, or indeed put back these checks otherwise.

If we're now in the C99 business, I'd prefer the attribute approach over reintroducing the checks. Let the compiler do the work (better). Essentially these become akin to C++ call by reference, which is largely avoids NPEs by having the call site syntax specify an object rather than its address, though one can of course bypass the safety with foo *x = NULL; func(*x, ...), which calls func() with a null pointer, and the crash happens inside func() when the referenced object is used.

Can you please point me to where in the C99 standard, attributes are introduced?
I'm unable to find them.

The null checks should be added. The attribute check for non-null args is definitely not universal. And we should be consistent as per Paul's comments. It significantly reduces support issues and it also helps reduce certain types of crashes.