compiling a db2 problem

[waner]

I'm new to db2. I've copied a small example program somewhere.My compiler is gcc. When I compile it I get some errors:
In file included from test2.c:20:
sqladef.h:96: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribu te__’ before ‘sqlaaloc’
sqladef.h:101: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribu te__’ before ‘sqlaAllocateCu rsorRS’
sqladef.h:106: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribu te__’ before ‘sqlaAssociateL ocatorRS’
sqladef.h:113: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribu te__’ before ‘sqlaAssocLocat orRS’
sqladef.h:120: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribu te__’ before ‘sqlacall’
sqladef.h:126: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribu te__’ before ‘sqlacmpd’
sqladef.h:132: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribu te__’ before ‘sqladloc’

What's wrong?? Thanks for help!

/* Prototypes for Runtime API's */

SQL_API_RC SQL_API_FN  sqlaaloc(unsigned short,
                                unsigned short,
                                unsigned short,
                                void *);

SQL_API_RC SQL_API_FN  sqlaAllocateCursorRS (
                                sqluint16,      
                                sqluint32,         
                                void *);

SQL_API_RC SQL_API_FN  sqlaAssociateLocatorRS (
                                sqluint32,      
                                int,         
                                char *,           
                                int,            
                                void *);

SQL_API_RC SQL_API_FN  sqlaAssocLocatorRS (
                                sqluint32 *,      
                                int,         
                                char *,           
                                int,            
                                void *);

SQL_API_RC SQL_API_FN  sqlacall(unsigned short,
                                unsigned short,
                                unsigned short,
                                unsigned short,
                                void *);

SQL_API_RC SQL_API_FN  sqlacmpd(unsigned short,
                                unsigned short,
                                unsigned short,
                                unsigned short,
                                void *);

[donbock]

Presumably those lines from sqladef.h are preceded by

#include "sqlsystm.h"              /* System dependent defines  */

What are the definitions of SQL_API_RC and SQL_API_FN in your copy of sqlsystm.h?

[waner]

Presumably those lines from sqladef.h are preceded by

#include "sqlsystm.h"              /* System dependent defines  */

What are the definitions of SQL_API_RC and SQL_API_FN in your copy of sqlsystm.h?

#if !defined SQL_API_RC
#define SQL_API_RC int
#define SQL_STRUCTURE struct
#define SQL_POINTER
#define SQL_API_FN __stdcall
#define SQL_API_INTR __stdcall
#define PSQL_API_FN __stdcall *
#endif


Is it?

[newb16]

http://bytes.com/topic/c/answers/811046-__stdcall-alternative#post3226690

[donbock]

This is not just a matter of making the compiler errors go away. __stdcall is a nonstandard compiler extension that alters the protocol used to call a function in ways that I frankly don't fully understand. Runtime problems could occur if the caller and called function use different calling protocols.

Do you expect your db2 program to execute on Windows or Linux? Does your compiler know it is generating code for that operating system?

Even without __stdcall, there is some risk that the db2 library functions expect a different calling protocol than is generated by your gcc compiler. Your db2 library documentation ought to specify what compilers and operating systems it is compatible with. Are you using a compatible environment?

I wanted to get your attention with these warnings. In actuality, gcc is a pretty common compiler. It is reasonable to believe that it provides some mechanism for supporting these db2 libraries of yours. (If so, I would expect it to take the form of a command-line switch rather than a #define in the source code, but this is only a guess.) My point is that you should always be concerned about compiler compatibility when you mix third-party pre-compiled libraries with new code. The library documentation ought to state the compiler compatibility constraints.

At this point I'll yield to gcc/linux/db2 experts who have personal experience with __stdcall.

[waner]

This is not just a matter of making the compiler errors go away. __stdcall is a nonstandard compiler extension that alters the protocol used to call a function in ways that I frankly don't fully understand. Runtime problems could occur if the caller and called function use different calling protocols.

Do you expect your db2 program to execute on Windows or Linux? Does your compiler know it is generating code for that operating system?

Even without __stdcall, there is some risk that the db2 library functions expect a different calling protocol than is generated by your gcc compiler. Your db2 library documentation ought to specify what compilers and operating systems it is compatible with. Are you using a compatible environment?

I wanted to get your attention with these warnings. In actuality, gcc is a pretty common compiler. It is reasonable to believe that it provides some mechanism for supporting these db2 libraries of yours. (If so, I would expect it to take the form of a command-line switch rather than a #define in the source code, but this is only a guess.) My point is that you should always be concerned about compiler compatibility when you mix third-party pre-compiled libraries with new code. The library documentation ought to state the compiler compatibility constraints.

At this point I'll yield to gcc/linux/db2 experts who have personal experience with __stdcall.

Thanks.I've tried as you say.The problem above isn't existed,though there is another problem appearing.