Hi,
On Thu, 20 Jul 2006 17:02:37 +0200
Gisle Vanem [EMAIL PROTECTED] wrote:
One other thing is that cmll_loc.h includes intypes.h for non-MSCV
targets. This header is not omni-present. A patch for djgpp at least:
I think you can compile on non-MSVC with Camellia code which is included
in
On Thu, Jul 20, 2006 at 03:26:55PM +0200, Andy Polyakov wrote:
The time span between original submission and update suggests that
contributors were planning the update, meaning that the code was
considered work in progress all along. If so, why it went into stable
branch?
I understand
The time span between original submission and update suggests that
contributors were planning the update, meaning that the code was
considered work in progress all along. If so, why it went into stable
branch?
I understand that two different implementations were developed in
parallel,
So
The time span between original submission and update suggests that
contributors were planning the update, meaning that the code was
considered work in progress all along. If so, why it went into stable
branch? Then this update quality... It's just wrong on several points.
Most notably
#ifdef
One other thing is that cmll_loc.h includes intypes.h for non-MSCV
targets. This header is not omni-present. A patch for djgpp at least:
--- crypto\camellia\cmll_loc.org2006-07-20 17:01:50 +0200
+++ crypto\camellia\cmll_loc.h 2006-07-20 16:57:54 +0200
@@ -77,6 +77,8 @@
typedef unsigned
One other thing is that cmll_loc.h includes intypes.h for non-MSCV
targets. This header is not omni-present. A patch for djgpp at least:
--- crypto\camellia\cmll_loc.org2006-07-20 17:01:50 +0200
+++ crypto\camellia\cmll_loc.h 2006-07-20 16:57:54 +0200
@@ -77,6 +77,8 @@
typedef unsigned
