#1148 CFFI improperly handles complex #defines

[Anonymous]

SWIG 2.0.2 (Mac OS X, installed from MacPorts) gets confused by the series of nested defines used in OpenCV2 for defining different types of data elements. I expect that running SWIG on OpenCV 2.2 core/types_c.h will generate a series of valid (constant) Lisp expressions for the following CV_MAKETYPE(depth,cn) invocations.

==========
#define CV_CN_MAX 512
#define CV_CN_SHIFT 3
#define CV_DEPTH_MAX (1 << CV_CN_SHIFT)

#define CV_8U 0
#define CV_8S 1
#define CV_16U 2
#define CV_16S 3
#define CV_32S 4
#define CV_32F 5
#define CV_64F 6
#define CV_USRTYPE1 7

#define CV_MAT_DEPTH_MASK (CV_DEPTH_MAX - 1)
#define CV_MAT_DEPTH(flags) ((flags) & CV_MAT_DEPTH_MASK)

#define CV_MAKETYPE(depth,cn) (CV_MAT_DEPTH(depth) + (((cn)-1) << CV_CN_SHIFT))
#define CV_MAKE_TYPE CV_MAKETYPE

#define CV_8UC1 CV_MAKETYPE(CV_8U,1)

However, for all uses of CV_MAKETYPE, invalid Lisp code similar to the following is generated:

==========
(cl:defconstant #.(swig-lispify "CV_8UC1" 'constant) (cl:logand (0 (cl:+ (cl:- (cl:ash 1 3) 1)) (cl:- ((1 1) << 3))))
==========

In particular, note the improperly balanced parentheses, invalid parentheses (i.e. (1 1) is not a valid Lisp expression) and failure to properly parse out the << operator from the original define. I attach both the C header file and the generated Lisp code.

[Anonymous]

Lisp/CFFI code generated for OpenCV 2.2 types_c.h

[William Fulton]

Closing all open CFFI issues as CFFI has been disabled, please see https://github.com/swig/swig/issues/1447