On 29/11/2019 10:29, Matthias St. Pierre wrote:
>
>
> On 29.11.19 10:22, Matt Caswell wrote:
>>
>> if (!ossl_assert(ptr != NULL)) {
>> ERR_raise(ERR_LIB_WHATEVER, ERR_R_PASSED_NULL_PARAMETER);
>> return 0;
>> }
>>
>
> I still dislike the odd way in which the assert
On 29.11.19 11:29, Matthias St. Pierre wrote:
On 29.11.19 10:22, Matt Caswell wrote:
if (!ossl_assert(ptr != NULL)) {
ERR_raise(ERR_LIB_WHATEVER, ERR_R_PASSED_NULL_PARAMETER);
return 0;
}
I still dislike the odd way in which the assertion needs to be formulat
On 29.11.19 10:22, Matt Caswell wrote:
if (!ossl_assert(ptr != NULL)) {
ERR_raise(ERR_LIB_WHATEVER, ERR_R_PASSED_NULL_PARAMETER);
return 0;
}
I still dislike the odd way in which the assertion needs to be formulated,
with the double negation. With the `ossl_is_n
Oops, you are correct. I was under the mistaken impression that ossl_assert
compiled to nothing outside of debug mode.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 29 Nov 2019, at 7:22 pm, Matt Caswell wrote:
>
>
On Fri, Nov 29, 2019 at 7:08 PM Tomas Mraz wrote:
> The "always check for NULL pointers" approach does not avoid
> catastrophical errors in applications.
I didn't say it avoided all errors (nor did anyone else on the thread that
I've read) - but it does avoid a whole class of errors.
And for t
On 29/11/2019 08:38, Dr Paul Dale wrote:
> I’d prefer option 1 or the middle ground. I’ve lost count of the
> number of times I’ve seen programs crashing in the crypto library
> which required mammoth debugging efforts to irrefutably demonstrate
> that the caller is at fault rather than the cry
The "always check for NULL pointers" approach does not avoid
catastrophical errors in applications. For example let's say an
application code encrypts some plaintext in-place and sends it out as
encrypted. Let's say we check for the NULL EVP_CIPHER_CTX in
EVP_CipherUpdate() but the app does not bot
I’d prefer option 1 or the middle ground. I’ve lost count of the number of
times I’ve seen programs crashing in the crypto library which required mammoth
debugging efforts to irrefutably demonstrate that the caller is at fault rather
than the crypto library :(
Option 1 would be preferable from
The way I view the issue is to look at what happens when things go wrong -
what is the impact - and evaluate the difference in behaviour between the
approaches.
You have to start from the premise that (in general) software is not tested
for all possible usage models - i.e. test coverage isn't at 10