Generating modified ddk files

Question

it would be really swell to be able to redefine many DDK functions to reduce extraneous overhead.  For example the function:
inline tMSeries::tInterrupt_A_Ack& tMSeries::tInterrupt_A_Ack::setG0_Gate_Error_Confirm(u16 fieldValue, nMDBG::tStatus2* s)
   if (s && s->isFatal()) return *this;
   u16 newValue;   newValue = ((u16)(_softCopy & 0xffdf)) | (((u16)fieldValue << 0x5) & ~0xffdf);
   setRegister(newValue, s);
   return *this;
could be redefined as
inline void tMSeries::tInterrupt_A_Ack::setG0_Gate_Error_Confirm(u16 fieldValue)
    u16 newValue;   newValue = ((u16)(_softCopy & 0xffdf)) | (((u16)fieldValue << 0x5) & ~0xffdf);
    setRegister(newValue);
removing the status param and getting rid of the function result signficantly reduces the stack requirements for the routine, when inlined.  of course optimization cleans up some of this, but not for debug builds.  i am having a problem with stack overflows, after moving to a new compiler and target (GCC 4.2, x86_64).
can anyone at NI comment on the feasibility of regenerating these files without the extra code?   of course I can do it by hand, but I don't see an easy way to automate removal of the function result...
thanks,
spg
scott gillespie
applied brain, inc.

Answer 1

Scott,
I had some time to look into this some more.  The short story is that these files are not easy to generate in a way that will help you prevent the stack overflows.  Because of this, I doubt that these types of files will be available from NI.
The Measurements DDK driver is meant as an example showing how to access the hardware registers on the NI DAQ boards.  Joe summed it up pretty well in this post.  To prevent your stack overflow issues in the future, you should use the DDK as a reference for creating a driver for your specific operating system and platform.
Thanks,
Steven T.