Subscribe for automatic updates: RSS icon RSS

Login icon Sign in for full access | Help icon Help
Advanced search

Pages: [1]
  Reply  |  Print  
Author Topic: Access to Call Stack and value_t structure  (Read 11069 times)
Bradford D.
Posts: 6


« on: February 06, 2015, 09:22:35 pm »

Is it possible to access the call stack pointer and the definitions within the Informix value.h file (value_t) in order to access information about the passed parameters?  Does Genero have any equivalent that would allow a C program to determine the type and size of the parameters on the stack in order to use the appropriate pop function to get the value?  I have an application that needs to pass a variable number of parameters to a C function and these parameters may differ in type from call to call.
Rene S.
Four Js
Posts: 111


« Reply #1 on: February 09, 2015, 08:16:27 am »

Hello, no, it's not possible to inspect the stack and query the type of values on the stack.
This has been asked before. Please let us know, if this missing feature is a show blocker for you. Those methods exists internally. We always hesitate in extending the C-API.

You say: "I have an application that needs to pass a variable number of parameters to a C function".
C-functions with a variable number of parameters may introduce compilation problems: the compiler (not only Genero fglcomp, also c4gl) checks the number of parameters. You can not call a c-function with different number of parameters from the same 4gl-moudule.

$ c4gl xx.4gl || cat xx.err
The compilation was not successful.  Errors found: 1.
The file "xx.err" has been written.
MAIN
    CALL foo(1)
    CALL foo(1, 2)
|
|      The function "foo" has already been called with a different
| number of parameters.
| See error number -4333.
END MAIN

Rene
Bradford D.
Posts: 6


« Reply #2 on: February 09, 2015, 11:45:40 am »

This very much is a show stopper.  Otherwise, there is no way to determine within the C function what type of parameter you are being passed.  I do not understand your reluctance to extend the C-API as this will do nothing but extend the overall capabilities of the language allowing experienced programmers to add functionality and increase the overall language flexibility of Genero.  This has been one of he main stays of Informix over the years and I would expect Fourj's should be more than willing to continue that philosophy.  I really don't see any downside here or risk to Fourj's.

C4GL had a flag to relax he restriction of function signature checking that allowed this exact type of use.  Most modern languages also allow this type of code and function call overloading.  To restrict this at compile time is simply too restrictive and is best IMHO left at run-time.  Even without this, the ability to manipulate data on and have access to the call stack is really crucial.

Brad
David H.
Posts: 158


« Reply #3 on: February 09, 2015, 01:00:16 pm »

...  I do not understand your reluctance to extend the C-API as this will do nothing but extend the overall capabilities of the language allowing experienced programmers to add functionality and increase the overall language flexibility of Genero.  This has been one of he main stays of Informix over the years and I would expect Fourj's should be more than willing to continue that philosophy.  I really don't see any downside here or risk to Fourj's.

Yes I agree. The more functionality available the better for me! We do still have one C function which allows us to dynamically call 4GL functions with a variable number of parameters both IN and OUT. It would be nice to have an ignore option to get around that compile time check with the same module...
Pages: [1]
  Reply  |  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines