Trouble getting QuantLibAddin to work with vc 7.1

[Plamen Neykov]

Hi All,

I'm having considerable trouble to get the QuantLibAddin (the Excel add-in) to
work. I'm using vc 7.1 and the add-in is crashing exactly as described in
Microsoft Knowledge Base Article ID 198477
( http://support.microsoft.com/kb/198477 ) It is crashing in TempStr as it
tries to change the first character of a string. I've for sure changed in all
projects the /ZI switch to /Zi and rempiled everything but still have the
same problem. Strange is that the add-in crashes also in the release config
(as by microsoft this should occur only with the debug config). Does anyone
know how to get this problem solved?

Thanks in advance
Plamen

[Ferdinando M. Ametrano-3]

At 07:08 PM 5/17/2005, you wrote:
>I'm having considerable trouble to get the QuantLibAddin (the Excel
>add-in) to
>work. I'm using vc 7.1 and the add-in is crashing exactly as described in
>Microsoft Knowledge Base Article ID 198477

if you're getting QuantLib-Addin from the CVS the Visual 7.1 project is
probably way outdated. Try opening the VC6 project and convert it to 7.1

ciao -- Nando  

[eric ehlers]

On 5/17/05, Plamen Neykov <[hidden email]> wrote:

> Hi All,
>
> I'm having considerable trouble to get the QuantLibAddin (the Excel add-in) to
> work. I'm using vc 7.1 and the add-in is crashing exactly as described in
> Microsoft Knowledge Base Article ID 198477
> ( http://support.microsoft.com/kb/198477 ) It is crashing in TempStr as it
> tries to change the first character of a string. I've for sure changed in all
> projects the /ZI switch to /Zi and rempiled everything but still have the
> same problem. Strange is that the add-in crashes also in the release config
> (as by microsoft this should occur only with the debug config). Does anyone
> know how to get this problem solved?
>
> Thanks in advance
> Plamen

Hi Plamen

I'm not aware of a situation where the modification of a literal
string causes an access violation in the absence of string pooling
(/ZI, /GF).

You could try visiting http://office.microsoft.com and installing any
available bugfixes for your copy of Excel.

Some other thoughts -
- QuantLibAddin ships the Excel project with string pooling disabled
and it shouldn't be necessary to disable it in related projects
- You should be using QuantLib 0.3.9 plus the latest CVS snapshots of
ObjectHandler and QuantLibAddin
- For ObjectHandler and QuantLibAddin the VC7/8 workspaces are updated
only for releases, when using VC7 against a CVS snapshot you should
upgrade the VC6 workspace.

Regards,
Eric

[Plamen Neykov]

On Wednesday 18 May 2005 11:41, eric ehlers wrote:

> On 5/17/05, Plamen Neykov <[hidden email]> wrote:
> > Hi All,
> >
> > I'm having considerable trouble to get the QuantLibAddin (the Excel
> > add-in) to work. I'm using vc 7.1 and the add-in is crashing exactly as
> > described in Microsoft Knowledge Base Article ID 198477
> > ( http://support.microsoft.com/kb/198477 ) It is crashing in TempStr as
> > it tries to change the first character of a string. I've for sure changed
> > in all projects the /ZI switch to /Zi and rempiled everything but still
> > have the same problem. Strange is that the add-in crashes also in the
> > release config (as by microsoft this should occur only with the debug
> > config). Does anyone know how to get this problem solved?
> >
> > Thanks in advance
> > Plamen
>
> Hi Plamen
>
> I'm not aware of a situation where the modification of a literal
> string causes an access violation in the absence of string pooling
> (/ZI, /GF).
>
> You could try visiting http://office.microsoft.com and installing any
> available bugfixes for your copy of Excel.
>
> Some other thoughts -
> - QuantLibAddin ships the Excel project with string pooling disabled
> and it shouldn't be necessary to disable it in related projects
> - You should be using QuantLib 0.3.9 plus the latest CVS snapshots of
> ObjectHandler and QuantLibAddin
> - For ObjectHandler and QuantLibAddin the VC7/8 workspaces are updated
> only for releases, when using VC7 against a CVS snapshot you should
> upgrade the VC6 workspace.
>
> Regards,
> Eric

Hi Eric,

unfortunately the following program crashes also exactly in the same way as
the add-in:

#include <iostream>
int main(int argc, char* argv[])
{
        char* p = "Test";
        p[0] = 'P';
        std::cout << p;
        return 0;
}

It doesn't matter which compiler switches I use to compile it - either in the
ide or via the command line. It crashes even if I compile it like that:
cl Test.cpp
My compiler version is 13.10.3077

It seems to me that my compiler is placing string literals _allways_ in
readonly memory disregarding the compiler switches I use .....

Thanks & Regards
Plamen

[eric ehlers]

On 5/18/05, Plamen Neykov <[hidden email]> wrote:

> Hi Eric,
>
> unfortunately the following program crashes also exactly in the same way as
> the add-in:
>
> #include <iostream>
> int main(int argc, char* argv[])
> {
>         char* p = "Test";
>         p[0] = 'P';
>         std::cout << p;
>         return 0;
> }
>
> It doesn't matter which compiler switches I use to compile it - either in the
> ide or via the command line. It crashes even if I compile it like that:
> cl Test.cpp
> My compiler version is 13.10.3077
>
> It seems to me that my compiler is placing string literals _allways_ in
> readonly memory disregarding the compiler switches I use .....
>
> Thanks & Regards
> Plamen

Hi Plamen

I guess this is the issue described here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/vclrfstringliteralshavepropertypeofconstchar[].asp

Interestingly at this link ...
http://support.microsoft.com/default.aspx?scid=%2Fservicedesks%2Fwebcasts%2Fen%2Ftranscripts%2Fwct032003.asp
... it says "You need to compile this code at a command prompt without
using any specific compiler switches" - but you tried that and it
didn't fix the problem - I assume that that unofficial document is out
of sync with your version of VC7.1.

I think it should be straightforward to refactor the TempStr function
to not use string literals, I'll look into this and get back to you.

Regards
Eric

[Plamen Neykov]

On Wednesday 18 May 2005 15:00, eric ehlers wrote:

> On 5/18/05, Plamen Neykov <[hidden email]> wrote:
> > Hi Eric,
> >
> > unfortunately the following program crashes also exactly in the same way
> > as the add-in:
> >
> > #include <iostream>
> > int main(int argc, char* argv[])
> > {
> >         char* p = "Test";
> >         p[0] = 'P';
> >         std::cout << p;
> >         return 0;
> > }
> >
> > It doesn't matter which compiler switches I use to compile it - either in
> > the ide or via the command line. It crashes even if I compile it like
> > that: cl Test.cpp
> > My compiler version is 13.10.3077
> >
> > It seems to me that my compiler is placing string literals _allways_ in
> > readonly memory disregarding the compiler switches I use .....
> >
> > Thanks & Regards
> > Plamen
>
> Hi Plamen
>
> I guess this is the issue described here:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/htm
>l/vclrfstringliteralshavepropertypeofconstchar[].asp
>
> Interestingly at this link ...
> <a href="http://support.microsoft.com/default.aspx?scid=%2Fservicedesks%2Fwebcasts%2">http://support.microsoft.com/default.aspx?scid=%2Fservicedesks%2Fwebcasts%2
>Fen%2Ftranscripts%2Fwct032003.asp ... it says "You need to compile this code
> at a command prompt without using any specific compiler switches" - but you
> tried that and it
> didn't fix the problem - I assume that that unofficial document is out
> of sync with your version of VC7.1.
>
> I think it should be straightforward to refactor the TempStr function
> to not use string literals, I'll look into this and get back to you.
>
> Regards
> Eric

Hi Eric,

I've took a look where the TempStr function is used - it comes predominantely
in the generated code - qladdin.cpp, I found only one reference elsewhere -
in the file xlutils.cpp. I think the python generaton procedure could be
easily changed in the way to generate in the first byte of a string literal
the size of it directly so that this doesn't have to be done run-time - I
could try to change it - what do you think?

Thanks,
Plamen

[eric ehlers]

On 5/18/05, Plamen Neykov <[hidden email]> wrote:

>
> Hi Eric,
>
> I've took a look where the TempStr function is used - it comes predominantely
> in the generated code - qladdin.cpp, I found only one reference elsewhere -
> in the file xlutils.cpp. I think the python generaton procedure could be
> easily changed in the way to generate in the first byte of a string literal
> the size of it directly so that this doesn't have to be done run-time - I
> could try to change it - what do you think?
>
> Thanks,
> Plamen

Hi Plamen,

Here's a revised TempStr function which should do the trick:

LPXLOPER TempStr(LPSTR lpstr)
{
    LPXLOPER lpx;

    lpx = (LPXLOPER) GetTempMemory(sizeof(XLOPER));

    if (!lpx)
    {
        return 0;
    }
/*
    lpstr[0] = (BYTE) lstrlen (lpstr+1);
    lpx->xltype = xltypeStr;
//    lpx->val.str = (PUCHAR) lpstr;
    lpx->val.str = lpstr;
*/
    int len = strlen(lpstr);
    lpx->xltype = xltypeStr;
    lpx->val.str = GetTempMemory(len);
    if (!lpx->val.str) return 0;
    strncpy(lpx->val.str, lpstr, len);
    lpx->val.str[0] = (BYTE) len-1;

    return lpx;
}

But your proposed solution is much preferable:
- faster
- no risk of exceeding available temp memory
- no VC7-specific hack
so if you're happy to implement that it would be hugely appreciated.

Regards,
Eric

[Plamen Neykov]

On Wednesday 18 May 2005 15:40, eric ehlers wrote:

> On 5/18/05, Plamen Neykov <[hidden email]> wrote:
> > Hi Eric,
> >
> > I've took a look where the TempStr function is used - it comes
> > predominantely in the generated code - qladdin.cpp, I found only one
> > reference elsewhere - in the file xlutils.cpp. I think the python
> > generaton procedure could be easily changed in the way to generate in the
> > first byte of a string literal the size of it directly so that this
> > doesn't have to be done run-time - I could try to change it - what do you
> > think?
> >
> > Thanks,
> > Plamen
>
> Hi Plamen,
>
> Here's a revised TempStr function which should do the trick:
>
> LPXLOPER TempStr(LPSTR lpstr)
> {
>     LPXLOPER lpx;
>
>     lpx = (LPXLOPER) GetTempMemory(sizeof(XLOPER));
>
>     if (!lpx)
>     {
>         return 0;
>     }
> /*
>     lpstr[0] = (BYTE) lstrlen (lpstr+1);
>     lpx->xltype = xltypeStr;
> //    lpx->val.str = (PUCHAR) lpstr;
>     lpx->val.str = lpstr;
> */
>     int len = strlen(lpstr);
>     lpx->xltype = xltypeStr;
>     lpx->val.str = GetTempMemory(len);
>     if (!lpx->val.str) return 0;
>     strncpy(lpx->val.str, lpstr, len);
>     lpx->val.str[0] = (BYTE) len-1;
>
>     return lpx;
> }
>
> But your proposed solution is much preferable:
> - faster
> - no risk of exceeding available temp memory
> - no VC7-specific hack
> so if you're happy to implement that it would be hugely appreciated.
>
> Regards,
> Eric

Hi Eric,

I've done the changes (but still have to test them!). Here the preliminary
changes I've done (I'll send you a proper diff file later on today if the
testing is ok ;-) ):

Addin/excel.py
13c13
< REGLINE    = '        TempStrNoSize("%s")%s'
---
> REGLINE    = '        TempStr(" %s")%s'
21,22d20
< def generateExcelStringLiteral(str): return '\\x%02X%s'%(len(str),str)
<
56c54
<     str1 = REGLINE % (generateExcelStringLiteral(text), suffix)
---
>     str1 = REGLINE % (text, suffix)


Addin/stub.Excel.regheader
12,14c12,14
<         TempStrNoSize("\x0AGetAddress"),
<         TempStrNoSize("\x03PR#"),
<         TempStrNoSize("\x0AGetAddress"),
---
>         TempStr(" GetAddress"),
>         TempStr(" PR#"),
>         TempStr(" GetAddress"),


Addins/Excel/xlutils.cpp
136c136
<         if (xlretSuccess != Excel(xlUDF, &xStr, 2, TempStr(" GetAddress"),
&xCaller))
---
>         if (xlretSuccess != Excel(xlUDF, &xStr, 2,
TempStrNoSize("\x0AGetAddress"), &xCaller))



Addins/Excel/framewrk.cpp
211a212,229

> LPXLOPER TempStrNoSize(LPSTR lpstr)
> {
>     LPXLOPER lpx;
>
>     lpx = (LPXLOPER) GetTempMemory(sizeof(XLOPER));
>
>     if (!lpx)
>     {
>         return 0;
>     }
>
>     lpx->xltype = xltypeStr;
> //    lpx->val.str = (PUCHAR) lpstr;
>     lpx->val.str = lpstr;
>
>     return lpx;
> }

Regards,

Plamen

[eric ehlers]

On 5/18/05, Plamen Neykov <[hidden email]> wrote:

> Hi Eric,
>
> I've done the changes (but still have to test them!). Here the preliminary
> changes I've done (I'll send you a proper diff file later on today if the
> testing is ok ;-) ):

Hi Plamen

Final diff received, many thanks - I've committed your changes to CVS,
please check it out and let me know if I messed anything up.

Thanks very much for fixing this up, much appreciated !!

Best Regards,
Eric