>> I have been following the recent LibreSSL developments quite active and
>> would like to contribute.
>>
>> I have some questions:
>>
>> - The accelerated assembly code for the crypto, is that gonna stay?
>
>Of course. Why do you think anyone would try to break code which works?
Because it is a
Speaking for myself here, but as far as LibreSSL is concerned, I'd say
my opinion has a certain weight.
> - The accelerated assembly code for the crypto, is that gonna stay?
Yes. Including existing code for platforms OpenBSD itself does not run
on (e.g. s390).
> - Why not use uint32_t and uint64
> I have been following the recent LibreSSL developments quite active and
> would like to contribute.
>
> I have some questions:
>
> - The accelerated assembly code for the crypto, is that gonna stay?
Of course. Why do you think anyone would try to break code which works?
> - Why not use uint3
Hello everyone,
I have been following the recent LibreSSL developments quite active and
would like to contribute.
I have some questions:
- The accelerated assembly code for the crypto, is that gonna stay?
- Why not use uint32_t and uint64_t all over (incl the APIs) instead of
custom XX_ULONG stu
