Various defects with C parsing with Checkpoint OPSEC API

[GoogleCodeExporter]

The freely available Checkpoint OPSEC API 
(http://www.opsec.com/cp_products/90.htm) has a lot of problems parsing with 
different versions of JNAerator. I've been trying with 0.9.6, 0.9.7, 0.9.8, and 
0.9.9. I'm now doing a lot of manual fixing on the headers to get things 
parsed. I've tried with both BridJ and JNA with various issues. I think this 
library would help present some good test cases.

What steps will reproduce the problem?
1. This code:
#if !defined (CPRESULT_DEFINED)
#define CPRESULT_DEFINED
/** cpresult declaration */
typedef int cpresult;
#endif /*CPRESULT_DEFINED*/

/* Create a cpresult value from name and number */
#define CP_DECLARE_CPRESULT2(_name,_code,_msg)  \
    enum { _name = ((cpresult)(_code)) }
/* general success
 * Note: value match COM's S_OK */
CP_DECLARE_CPRESULT2 (CP_S_OK, 0x00000000L, "The Operation Finished 
Successfully");
Will preprocess out to the following:
enum { CP_S_OK = ((cpresult)(0x00000000L)) };

I modified this to remove the cast (cpresult) and it works with 0.9.6, and I 
think 0.9.7 but not 0.9.8 & 0.9.9. No code is generated under the latter 
release.
Under 0.9.7 it generates this code:
public static final int CP_S_OK = (0);
Which is okay.

2. There are a lot of these. These do not correctly generate global symbols 
under 0.9.6 & 0.9.7 but do under 0.9.8 & 0.9.9:
DLLIMP extern OpsecEntityType *CPMI_CLIENT;
DLLIMP extern OpsecEntityType *CPMI_SERVER;

3.
These kind of #defines don't seem to be supported at all:
#define _NEW_EN(n, server) (((n)<<1) | server)
#define OPSEC_GENERIC    _NEW_EN(0,0)     /* should be zero */
#define OPSEC_RPC        _NEW_EN(0,1)

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?
Variously 0.9.6, 0.9.7, 0.9.8, 0.9.9...

Is the problem still present in the latest SVN version ? (you can easily
build from sources with these instructions :
http://code.google.com/p/javacl/wiki/Build)

Please provide any additional information below.

Original issue reported on code.google.com by crobe...@bongle.co.uk on 30 Aug 2011 at 6:16

[GoogleCodeExporter]

Hello,

Thanks a lot for your detailed report and investigation, this is much 
appreciated !
I'll look into this asap... In the meanwhile, have you tried some of the 
command line options that affect parsing, such as -parseInOneChunk 
(http://code.google.com/p/jnaerator/wiki/CommandLineOptionsAndEnvironmentVariabl
es) ?

Cheers
--
zOlive

Original comment by olivier.chafik@gmail.com on 30 Aug 2011 at 1:12

• Changed state: Accepted
• Added labels: Priority-Critical
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I did more debugging on this. 
For issue 1 the problem is the anonymous/unnamed enum.

It seems like we store the enums in a Hash as enumsByName in Result.java:
    public Map<Identifier, Enum> enumsByName = new HashMap<Identifier, Enum>();

Then we check if the enum already exists:
        Identifier name = e.getTag();
        Enum oldEnum = enumsByName.get(name);
        if (oldEnum  == null || oldEnum.isForwardDeclaration() || (!(oldEnum.getParentElement() instanceof TypeDef) && oldEnum.getParentElement() instanceof TypeDef)) {

before we add the enum to the list. In the case of my enums the name is 'null' 
and there are multiple in the file. This means only the first 'null' named enum 
makes it into enumByName and enumByLibrary.
In a pinch I moved this:
            getList(enumsByLibrary, lib).add(e);

Outside of the 'if' statement to make sure it's added to the enums list even if 
it exists in the hash.

This works for me.

Original comment by crobe...@bongle.co.uk on 30 Aug 2011 at 1:14

[GoogleCodeExporter]

Okay, this worked to get all the enums built with my parsed copy. But the cast 
still doesn't work:
((cpresult)(_code))

Original comment by crobe...@bongle.co.uk on 30 Aug 2011 at 6:44

[GoogleCodeExporter]

Hello,

Thanks for your continued input !
I've committed a fix (deployed as 0.9.9-SNAPSHOT on Maven) for the anonymous 
enums inspired by your suggestion, along with fixes in the way enum items refer 
to other items with the BridJ runtime target :
https://github.com/ochafik/nativelibs4java/commit/0212fdde787b58ad3912950939fd42
6b20a09c9c

I'll now look into the other problems you've reported :-)
Cheers
--
zOlive

Original comment by olivier.chafik@gmail.com on 31 Aug 2011 at 8:52

• Changed state: Started

[GoogleCodeExporter]

Hi again,

Problem 2) was indeed fixed in 0.9.8 
(https://github.com/ochafik/nativelibs4java/commit/f54523bb35d8a41262842eca17944
1491c62a32d), and I've just deployed a fix for problem 3) :
https://github.com/ochafik/nativelibs4java/commit/6a1d485bcad138d854aaf09c62c2e2
ada1f0a61b

Thanks again for your help !
Cheers
--
zOlive

Original comment by olivier.chafik@gmail.com on 31 Aug 2011 at 11:12

• Changed state: Fixed