> Here is an updated version of the patch.
>
> Addressing a) "pointer to the function" (to select ADCX/ADOX) and b)
> multiple points addition
>
> There is (only) ~1% performance deterioration in due to the pointer being
> passed now, instead of (originally) being static. You can choose which
> sty
Hello,
there are two sets of DH parameters, is there a difference?
./crypto/dh/dh2048.pem
./crypto/dh/dh512.pem
./crypto/dh/dh192.pem
./crypto/dh/dh4096.pem
./crypto/dh/dh1024.pem
./apps/dh2048.pem
./apps/dh512.pem
./apps/dh4096.pem
./apps/dh1024.pem
In DH parameters in ./apps there reference to
Yes. It also works.
Regards,
Marcelo Cerri
On Thu, Nov 07, 2013 at 02:07:41PM +0100, Dr. Stephen Henson wrote:
> On Thu, Nov 07, 2013, Marcelo Cerri wrote:
>
> > Hi, any news on that?
> >
> > On Tue, Oct 29, 2013 at 05:01:03PM -0200, Marcelo Cerri wrote:
> > > In some platforms, such as POWER,
Hi,
These are the performance results for the little-endian for all the
affected algorithms and also MD5 and DES, which can be used as
reference.
All data was collected using VMs with the same spec (1 core and 1GB of
ram) and using linux kernel 3.10.9 and GCC 4.8.
All 'numbers' are in 1000s of b
On Fri, Nov 8, 2013 at 4:08 AM, Bodo Moeller via RT wrote:
> Alternatives would be (a) using a new lock for safe static initialization,
Maybe you could try my patches on my thread_safety branch of my github
clone of OpenSSL? (https://github.com/nicowilliams/openssl)
Nico
--
>> Here is an updated version of the patch.
>>
>> Addressing a) "pointer to the function" (to select ADCX/ADOX) and b)
>> multiple points addition
>>
>> There is (only) ~1% performance deterioration in due to the pointer being
>> passed now, instead of (originally) being static. You can choose whic
Andy, do you think the changes in the config scripts can already be
committed?
Sure. Basically, explicit confirmation that everything works would have
sufficed. Only one remaining thing. As for config patch, I don't quite
understand. From what was discussed I've got impression that LE system
> I encountered a number of unusual (but mostly minor) errors in building
> 1.0.1e on Tru64 V4.0G, configuration tru64-alpha-cc. I've addressed the
> majority of these in the 20131106 snapshot, and the changes are in the
> attached patch. Here is a walk-through:
>
> crypto/Makefile,
> crypto/bn/Ma
On Fri, Nov 8, 2013 at 2:43 PM, Andy Polyakov via RT wrote:
>> Alternatives would be (a) using a new lock for safe static initialization,
>> or (b) more code duplication to avoid the need for an explicit pointer
>> (there could be two separate implementations for the higher-level
>> routines). Ho
> While if (functiona==NULL || functionb==NULL) { asssign functiona,
> functionb } can be unsafe, I'd argue that if (functiona==NULL) { assign
> functiona } followed by if (functionb) { assign functionb } is.
>
We're implicitly assuming here that (thanks to alignment, etc.) each
pointer can be acc
On Fri, 2013 Nov 8 23:05+0100, Andy Polyakov via RT wrote:
> >
> > * Tru64 cc(1) can't preprocess stdin; it needs a file
>
> You can't make such broad statement, as it was verified to work on
> 5.x.
Well, it doesn't work for 5.1:
$ uname -a
OSF1 darkstar V5.1 732 alpha
$ echo __osf__
11 matches
Mail list logo
