Jakob Bohm via openssl-users writes:
> Performance wise, using a newer compiler that implements int64_t etc. via
> frequent library calls, while technically correct, is going to run
> unnecessarily slow compared to having algorithms that actually use the
> optimal integral sizes for the
Michael Wojcik via openssl-users writes:
> I'm inclined to agree. While there's an argument for backward
> compatibility, C99 was standardized nearly a quarter of a century
> ago. OpenSSL 1.x is younger than C99. It doesn't seem like an
> unreasonable requirement.
That and there is no
Dennis Clarke via openssl-users writes:
> On 11/2/22 07:30, Tomas Mraz wrote:
>> No, long long and unsigned long long is required and it was required
>> for quite some time. The code is mostly C90 but not strictly.
>> I suppose on platforms with 64bit long type we could make it work
>> without
Michael Wojcik writes:
> No, for a number of reasons:
> - The buffer may be dynamically allocated, in which case sizeof buffer
> is very much the wrong thing.
Obviously then you would use whatever variable you have the buffer size
in rather than sizeof. The point is that you just tell strncpy
Michael Wojcik writes:
> Some C experts have argued that the length-checking versions of the library
> functions, either the C90 ones such as strncat or the Appendix K ones, are
> essentially pointless anyway; that the caller needs to handle truncation and
> so ought to know whether
Jakob Bohm via openssl-users writes:
> 2. cd to /etc/ssl/certs and run the command
> /etc/sssl/certs# c_rehash
> (This updates the numeric symlinks to certificates so openssl can
> more easily find them).
Thanks, I ended up finding c_rehash and that did the trick.
I've been trying to convince git send-email to connect to my personal
smtp server without success. It keeps complaining that the cert is
self-signed. I thought all I had to do was add the cert to
/etc/ssl/certs and that should fix it, but it doesn't. Even without
doing this, and using
