Thread: Syntax question about c-mex s-functions

  1. #1
    Registered User
    Join Date
    Jun 2010
    Posts
    67

    Syntax question about c-mex s-functions

    I'm creating a c-mex s-function that calls functions from an existing library. However, due to the way that the code is set up, I need to perform an extra step when calling these functions, by creating a pointer to each function. I have one function correctly set up -- the code compiles without problems, and the generated mex file can be successfully used. However, I'm trying to duplicate this working, template setup for several other functions, and am now getting a puzzling compile error. Details are below:

    My correctly functioning code is:
    Code:
    typedef bool (*cwPointer)(int arg1, int arg2, char *fileName);
    HINSTANCE dll; /* Pointer to the .dll */
    cwPointer cw; /* Pointer to "cw" function within the .dll */ 
    dll = LoadLibrary("AC.dll");
    cw = (cwPointer)GetProcAddress(dll, "cw");
      
    cw(1, 4, "SetupFile.txt");  /* call to the function */

    And here is the 2nd function that I'm attempting to declare and use in the same way:
    Code:
    typedef int (*gawPointer)(double *arg1, double *arg2);
    gawPointer gaw; /* Pointer to "gaw" function within the .dll */  
    gaw = (gawPointer)GetProcAddress(dll, "gaw");
    gaw(*state, *actionBuff);
    Note that I excluded the "HINSTANCE dll" and "LoadLibrary" lines from the second set of code, since these only need to be included a total of once.

    When this second set of code is included, I get compile failure, and the error messages include:

    error C2143: syntax error : missing ';' before 'type'
    --> this refers to the first line of the 2nd set of code; I notice that in the first set of code, within my code editor, "typedef" is in blue and "bool" is in black, indicating that only "typedef" is a reserved keyword. However, in the second set of code, both "typedef" *and* "int" are blue, indicating that, for some reason, the compiler is not interpreting these 2 similar "typedef" statements above equivalently.

    Any suggestions about what I might need to do to resolve this error? Thanks in advance for your help!
    Last edited by CodeKate; 08-30-2011 at 11:26 AM.

  2. #2
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,662
    > error C2143: syntax error : missing ';' before 'type'
    Look for a missing ; a few lines earlier in the code.

    If this line appears immediately after a #include, then look in the last included file for missing ;
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  3. #3
    Registered User
    Join Date
    Nov 2010
    Location
    Long Beach, CA
    Posts
    5,909
    I think it's confused by your use of bool, which was not added until C99. You need to make sure you're using a C99 compiler and #include <stdbool.h>.

  4. #4
    Registered User
    Join Date
    Jun 2010
    Posts
    67
    Thanks for your input, Salem & anduril.

    Look for a missing ; a few lines earlier in the code.
    If this line appears immediately after a #include, then look in the last included file for missing ;
    The 2 sections of code I posted above are in the same order in my actual code, i.e. the 2nd section immediately follows the first, and I don't see any missing semicolon in the first section...


    I think it's confused by your use of bool, which was not added until C99. You need to make sure you're using a C99 compiler and #include <stdbool.h>.
    When I added this new #include statement, the compile still fails, and I now get the compiler warning:
    C:\watcom\H\stdbool.h(35) : warning C4068: unknown pragma

    Can you clarify what you mean by a "C99" compiler? I'm currently using a Watcom compiler (what's odd is that I specifically used the mex -setup utility to try to change the compiler to Visual C++ 2008, but I'm still getting the above messsage, even after that supposed compiler change).

  5. #5
    Registered User
    Join Date
    Nov 2010
    Location
    Long Beach, CA
    Posts
    5,909
    Wow, didn't know people still used Watcom, or that it was at all current. C99 refers to the 1999 version of the ISO C standard. That version added some features to the standard from 1989/1990. Some compilers don't support all the new features, and many require you to explicitly enable C99 features. According to this Wikipedia article on C99, OpenWatcom (is that what you're using?) doesn't fully support C99 and the switch to enable it is officially undocumented (a bit more Googling will turn something up I suppose).

    If you're still having too much trouble with that, you may want to move to something a little more mainstream, like Pelles C, Code::Blocks/MinGW, GCC. All are free and support most or all of C99.

  6. #6
    Registered User
    Join Date
    Jun 2010
    Posts
    67
    My concern is that I'm using Matlab R2009b & the associated version of Simulink, and I need a compiler that is specifically compatible with this version. This is the official list: Support - Supported / Compatible Compilers - Release 2009b

    I also just noticed that "bool" *never* appears as a reserved keyword in my code (when viewed from the Visual C++ 2008 Express Edition editor). e.g., in a string of function arguments of various types, "int", "double", etc. will all be in blue type, but "bool" is always black. This seems like a fundamental problem; it's interesting that the editor displays this problem, but the compiler allows the first example above to compile with no problems...

  7. #7
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by CodeKate View Post
    My concern is that I'm using Matlab R2009b & the associated version of Simulink, and I need a compiler that is specifically compatible with this version. This is the official list: Support - Supported / Compatible Compilers - Release 2009b

    I also just noticed that "bool" *never* appears as a reserved keyword in my code (when viewed from the Visual C++ 2008 Express Edition editor). e.g., in a string of function arguments of various types, "int", "double", etc. will all be in blue type, but "bool" is always black. This seems like a fundamental problem; it's interesting that the editor displays this problem, but the compiler allows the first example above to compile with no problems...
    Stuff this in a header file or at the top of your page...

    Code:
    typedef int bool;
    #define BOOL bool
    #define TRUE 1
    #define FALSE 0

  8. #8
    Registered User
    Join Date
    Nov 2010
    Location
    Long Beach, CA
    Posts
    5,909
    Don't think that the syntax highlighting is going to reflect the exact version of the language you're going to compile. Especially when your editor is MSVC++ and your compiler OpenWatcom. Also note that MSVC++ doesn't support any of the new features in C99 (i.e. they only support the 1989/1990 standard), and doesn't plan on doing so, so it's syntax highlighting is not reliable for determining language features. Google for enabling C99 features in OpenWatcom, you should find some info on support for bool, and how to enable it. If that doesn't work, make your own version of stdbool.h called mybool.h or some such.

  9. #9
    Registered User
    Join Date
    Jun 2010
    Posts
    67
    Thanks for your suggestion, Tater. I did add your code, and I see that, apparently, my compiler *does* recognize the bool type. The compile error that I now receive is:

    error C2371: 'bool' : redefinition; different basic types
    cMEXsfcn.c(20) : see declaration of 'bool'

    I'm not sure what the implication is. Is it possible that the issue of my editor not appearing to recognize 'bool' as a reserved type, may be a red herring? (Update: I see that anduril agrees, above.) Again, the first code example above (which contains the bool type) *does* compile and run without error, while it's the *second* set of code that fails. When I comment out the first section of code and only compile the second section (with the 2 deleted lines now restored), I still get a bunch of compile errors. When the first section is commented out, now the first line that is complained about is the function call on the last line of the 2nd code chunk. The error message concerns the argument type being used; maybe I will do some more investigating to ensure that all argument types & values are legit.
    Last edited by CodeKate; 08-30-2011 at 12:59 PM.

  10. #10
    Registered User
    Join Date
    Nov 2010
    Location
    Long Beach, CA
    Posts
    5,909
    Post your specific error messages, and we can help you for sure with the type thing.

    I'm going to take a stab in the dark here though. If state and actionBuff are of type double, you need &state and &actionBuff to get their addresses (pointer to a double). Putting a * in front like that dereferences a pointer, which takes a pointer-to-double and gives you the double it points at. Note that if they are arrays of doubles (actionBuff sounds like one), just pass in state or actionBuff with no &. The name of the array acts like a pointer to the first element when passed to a function.

  11. #11
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Best bet... look in cMEXsfcn.c Line 20... see what's there. If possible move it to a header so you can include it everywhere...

    Funny thing about error messages... they tend to tell you exactly what's going on.

  12. #12
    Registered User
    Join Date
    Jun 2010
    Posts
    67
    My specific error message is:
    CMEXsfcn.c(312) : error C2440: 'function' : cannot convert from 'double' to 'double *'

    The problematic function call is:
    Code:
    getActionWrapper(*temp830, *actionBuff, dt, includeNoise);
    If I specify the first 2 arguments of the function call as "&argument", the new error message I get is:
    CMEXsfcn.c(312) : warning C4047: 'function' : 'double *' differs in levels of indirection from 'double **'


    The function specification line is:
    Code:
     typedef int (*gawPointer)(double *state, double *actionBuff, double dt, bool includeNoise);
    The declarations of the 4 arguments are (local variables within the same function):

    double *actionBuff, *temp830, dt = 0.02;
    bool includeNoise;

    Ah... if I exclude any prefixes, and just specify the first 2 arguments as "arg1" and "arg2", the compiler errors above disappear. Keeping the rest of the post above, for reference purposes.

    Thanks for your input, everyone. I need to keep in mind that a compiler error about one particular line (the 'missing semicolon' error I had been getting) might be caused by a completely unrelated problem in a different line of code...
    Last edited by CodeKate; 08-30-2011 at 01:29 PM.

  13. #13
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,662
    > The 2 sections of code I posted above are in the same order in my actual code, i.e. the 2nd section immediately
    > follows the first, and I don't see any missing semicolon in the first section...
    In which case, the other C99 feature you're missing is the ability to mix declarations and statements.

    Code:
    typedef bool (*cwPointer)(int arg1, int arg2, char *fileName);
    HINSTANCE dll; /* Pointer to the .dll */
    cwPointer cw; /* Pointer to "cw" function within the .dll */ 
    dll = LoadLibrary("AC.dll");
    cw = (cwPointer)GetProcAddress(dll, "cw");
      
    cw(1, 4, "SetupFile.txt");  /* call to the function */
    
    typedef int (*gawPointer)(double *arg1, double *arg2);
    gawPointer gaw; /* Pointer to "gaw" function within the .dll */  
    gaw = (gawPointer)GetProcAddress(dll, "gaw");
    gaw(*state, *actionBuff);
    The red lines need moving up.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  14. #14
    Registered User
    Join Date
    Jun 2010
    Posts
    67
    Great observation; I'll keep that in mind as I work to implement the rest of my functions.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Syntax for functions
    By Mentallic in forum C Programming
    Replies: 2
    Last Post: 08-27-2011, 12:11 AM
  2. Syntax for Declaring Functions in Dev-C++
    By Muz in forum C Programming
    Replies: 4
    Last Post: 07-03-2007, 04:53 AM
  3. Syntax Help, class interactions and functions..
    By Shamino in forum C++ Programming
    Replies: 18
    Last Post: 05-17-2007, 01:09 PM
  4. Replies: 3
    Last Post: 10-31-2006, 02:15 AM
  5. Geometry-shapes functions' syntax ?
    By bigjoke in forum C Programming
    Replies: 9
    Last Post: 01-01-2006, 10:25 PM