Insight into a possible bug...

[Colin Doncaster]

Hi there - 

On Linux and OSX everything seems to be happy, but I seem to be getting a crash on windows that is caused by the code generated from the "free" in line in the bison file

| VAR { $$ = NODE1(@$.first_column,@$.last_column,VarNode, $1); free($1); /* free name string */ }

I'm just starting to dig deeper but I thought I'd check and see if anyone could shed the light on why it might be happening.  It could very well have something to do with the way I'm handling variables but it would be odd that it's the string de-allocation that's causing it. 

Thanks 

[Colin Doncaster]

FWIW - it seems like the issue on Windows is that SeExprParserLex.l is using strdup in 

${IDENT} { yylval.s = strdup(&yytext[1]); return VAR; }

( and many other places )  

which are POSIX functions which have been deprecated on Windows and know for trashing memory vs the ISO C++ _strdup, when switched it seems happy.

http://msdn.microsoft.com/en-us/library/ms235454%28v=vs.80%29.aspx

I think I'm going to have to created a STRDUP define to wrap all the calls in to make sure it's happy cross platform. 

Am I really the first one to come across this?  

Cheers

[Andrew Selle]

We don't use SeExpr in production on Windows at Disney. I did port it
to windows before the Open Source release, but the amount of testing
of course was much less than the Linux use received. SePlatform.h
already has many such defines. Sorry for the difficulty and thanks for
digging deeper.

-Andy

[Colin Doncaster]

No worries, that's what I figured - if we were just using Yeti in our own productions the Windows port wouldn't be an issue but as some of our clients are still Windows based we're stuck dealing with the "intricacies" of the platform.

BTW - line 158 in SeExpression.cpp causes more issues on Windows:
int* bound=lower_bound(&*lines.begin(),&*lines.end(),_errors[i].startPos);

I'm not %100 why you're dereferencing a reference but this causes a "vector iterator not dereferencable " exception which actually makes perfect sense, what does it mean to dereference lines.end() as it's an iterator pointing to the point past the last element.

Is there any reason why it can't be:
int bound=*(lower_bound(lines.begin(),lines.end(),_errors[i].startPos));
int line=bound-(*lines.begin()) + 1;
//int column=_errors[i].startPos-lines[line-1];
sstream<<" Line "<<line<<": "<<_errors[i].error<<std::endl;

or was the intention of the code at that point different?

I was going to fork the SeExpr project on github and commit the changes I'm making so you can review and integrate if you feel inclined. :)

Thanks again!

[Andrew Selle]

> BTW - line 158 in SeExpression.cpp causes more issues on Windows:
> int* bound=lower_bound(&*lines.begin(),&*lines.end(),_errors[i].startPos);
>
> I'm not %100 why you're dereferencing a reference but this causes a "vector iterator not dereferencable " exception which actually makes perfect sense, what does it mean to dereference lines.end() as it's an iterator pointing to the point past the last element.
>
> Is there any reason why it can't be:
> int bound=*(lower_bound(lines.begin(),lines.end(),_errors[i].startPos));
> int line=bound-(*lines.begin()) + 1;
> //int column=_errors[i].startPos-lines[line-1];
> sstream<<"  Line "<<line<<": "<<_errors[i].error<<std::endl;
>

This looks fine. I can't think of a reason that it was done the other
way (even though I'm pretty certain I wrote that line)

> or was the intention of the code at that point different?
>
> I was going to fork the SeExpr project on github and commit the changes I'm making so you can review and integrate if you feel inclined.  :)
>

perfect

-Andy

[Colin Doncaster]

I've committed the changes to
https://github.com/colindoncaster/SeExpr

cheers