This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Problems with init of a function pointer

Hello

I've a problem when initializing a global function pointer. Depending on where the function pointer is created, the adress of the funciton pointer is 0 (=wrong). There are no warnings in the compiler!
Compiler: c166 v4.23
Tool: uVision2 v2.31

Example:

typedef UINT16 (*pModul_Para)(UINT16, UINT16 *, void *, UINT16);

//prototype of the function
UINT16 Controller_Para(UINT16 ParamNr, UINT16 *pElementNr, void *pValue, UINT16 Action);

//create and init the function pointer
pModul_Para FunctionPtr123 = &Controller_Para;

//Function definition
UINT16 Controller_Para(UINT16 ParamNr, UINT16 *pElementNr, void *pValue, UINT16 Action)
{ ...
}

//create and init a second function pointer
pModul_Para FunctionPtr55 = &Controller_Para;

--> Result: FunctionPtr123 would be 0, FunctionPtr55 can be the address of Controller_Para.

Any idea? Thanks!

Parents
  • I have a self-made tool (on PC) ...

    Sounds like a self-made rudimentary in-circuit debugger. A full-featured debugger would be more convenient.
    Anyway, the ultimate test would be to actually use the contents of the variable in your program. Like in a call to printf(). It could still be compiler optimization at work. Although I don't remember seeing any wonders of optimization from the C166 compiler.

Reply
  • I have a self-made tool (on PC) ...

    Sounds like a self-made rudimentary in-circuit debugger. A full-featured debugger would be more convenient.
    Anyway, the ultimate test would be to actually use the contents of the variable in your program. Like in a call to printf(). It could still be compiler optimization at work. Although I don't remember seeing any wonders of optimization from the C166 compiler.

Children
  • Anyway, the ultimate test would be to actually use the contents of the variable in your program. Like in a call to printf(). It could still be compiler optimization at work.

    When I try to call the function with the "wrong" pFunktionPointer_1 then the program will crash. So I only read the function pointer (without calling it) with function Test()
    Result:
    pFunktionPointer_12 = 0 (wrong !!!)
    pFunktionPointer_22 = correct
    pFunktionPointer_32 = correct

    #include <STDLIB.H>
    
    //Typedef of the function pointer
    typedef unsigned int (*pModul_Parameter)(unsigned int, unsigned int *, void *, unsigned int);
    
    //prototype of the function below
    unsigned int CallThisFunction(unsigned int ParamNr, unsigned int *pElementNr, void *pValue, unsigned int Action);
    
    //create and init the function pointer 1
    pModul_Parameter pFunktionPointer_1 = &CallThisFunction;
    
    //prototype of the function below
    unsigned int CallThisFunction(unsigned int ParamNr, unsigned int *pElementNr, void *pValue, unsigned int Action);
    
    //create and init the function pointer 2
    pModul_Parameter pFunktionPointer_2 = &CallThisFunction;
    
    unsigned int CallThisFunction(unsigned int ParamNr, unsigned int *pElementNr, void *pValue, unsigned int Action)
    {
      //Do anything
      static int q = 88;
      return ++q;
    }
    
    //create and init the function pointer 3
    pModul_Parameter pFunktionPointer_3 = &CallThisFunction;
    
    
    
    void Test(void)
    {
      static pModul_Parameter pFunktionPointer_12, pFunktionPointer_22, pFunktionPointer_32;
    
     pFunktionPointer_12 = pFunktionPointer_1;
     pFunktionPointer_22 = pFunktionPointer_2;
     pFunktionPointer_32 = pFunktionPointer_3;
    
    }
    

  • So I only read the function pointer (without calling it) with function Test()

    That's insufficient. Your program must produce observable "side effects" that depend on the value of the variable, according to the C standard.

    When I try to call the function with the "wrong" pFunktionPointer_1 then the program will crash.

    That would probably qualify as a real "side effect". Although we didn't see the actual code.

    As I said before, this is probably a compiler and/or linker bug.

  • I forgot to mention that compiler/linker bugs should be reported to Keil. You can wait for a fix from them (requires a support contract, I think.)
    In the meantime, you can use some kind of a workaround. I think you found one: extra function prototypes and variables isolate the bug to a controllable area.