Re: Technically an API break

2020-05-07 Thread Matt Caswell
On 07/05/2020 16:02, Brian Smith wrote: > This kind of change might cause memory unsafety issues unless the > application is recompiled. At least, it's worth investigating that. > > On most platforms the ABI of a function that returns `void` and one that > returns `int` is the same, from the

Re: Technically an API break

2020-05-07 Thread Brian Smith
Matt Caswell wrote: > PR11589 makes a change to the public API function > `SSL_set_record_padding_callback` to change its return type from void to > int: > > https://github.com/openssl/openssl/pull/11589 > > This is technically an API break - but it doesn't seem too seriou

Re: Technically an API break

2020-05-07 Thread Richard Levitte
> > > https://github.com/openssl/openssl/pull/11589 > > > > This is technically an API break - but it doesn't seem too serious. > > It's > > possible, I suppose, that existing applications that use this will > > fail > > to spot the error return since t

Re: Technically an API break

2020-05-07 Thread Tomas Mraz
On Thu, 2020-05-07 at 09:24 +0100, Matt Caswell wrote: > PR11589 makes a change to the public API function > `SSL_set_record_padding_callback` to change its return type from void > to > int: > > https://github.com/openssl/openssl/pull/11589 > > This is technically an AP

Technically an API break

2020-05-07 Thread Matt Caswell
PR11589 makes a change to the public API function `SSL_set_record_padding_callback` to change its return type from void to int: https://github.com/openssl/openssl/pull/11589 This is technically an API break - but it doesn't seem too serious. It's possible, I suppose, that existing applications