Jump to content
  • Advertisement
Sign in to follow this  
Ricky C.

Context::GetLineNumber API reversed?

This topic is 2184 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'd been tracking a bug in our game engine when I suddenly realized that all my old tests had inverted. Has this method changed what it returns for non-zero values passed to the first parameter? I've not changed AS versions since my last test, so either I mis-observed or mis-documented, however unlikely. Whatever's the case there's something odd here - and none of it fits what I expect.

Previously I was tracking that I was getting the line number of the executable line one previous to where I expected when passing a value of 1. Now I'm getting the line number of the executable line after what I expect.

I'm using AS 2.23.1 currently. I do not rem I know, I do need to upgrade... Will likely catch it in 2.24.1 as working on a mess of other things at the moment - and 2.24.1 will likely contain the Xcode/Clang fixes I'm currently patching in manually.

Here's what I'm doing in C++:

std::string GetPreviousCallstackLine(const unsigned int& callstack_line_number) {
asIScriptContext* ctx = asGetActiveContext();

std::string result;

if (ctx != nullptr && callstack_line_number < ctx->GetCallstackSize()) {
asIScriptFunction* func;
const char* script_section;
int line, column;

func = ctx->GetFunction(callstack_line_number);
line = ctx->GetLineNumber(callstack_line_number, &column, &script_section);

result = std::string(script_section) + "(" + boost::lexical_cast<std::string>(line) + "):" + std::string(func->GetDeclaration());

return result;

// ... over in registration

ret = this->engine->SetDefaultNamespace("Engine::Debug"); assert(ret >= 0);
ret = this->engine->RegisterGlobalFunction("string GetPreviousCallstackLine(const uint &in a = 1)", asFUNCTION(GetPreviousCallstackLine), asCALL_CDECL); assert(ret >= 0);

// ...

And my use in AS is as such:

namespace UnitTest {
// ...
void EXPECT_TRUE (const bool&in a, string message = "") { if (!a) { Engine::LOG(Engine::LOG_PRIORITY::ERR, "EXPECT_TRUE failed in " + Engine::Debug::GetPreviousCallstackLine() + "! " + message); gTestStatus = false; } }

// ... This I will line number with arbitrary numbers for our reference:
100: EXPECT_TRUE(true);
102: EXPECT_TRUE(false);
103: // Just another blank line
104: EXPECT_TRUE(true);
107: EXPECT_TRUE(false);

I expect to have a message in my logger stating a line number of 102 for the first invalid test. In the past I instead got line 100, line 101 being skipped because it is blank. Currently I get line 104. Now, this is a trivial example, but it demonstrates what I've observed from the output of many variations. EXPECT_EQ, EXPECT_NE, and many other such functions all exhibit the same behavior, and it matter not what the previous or next executable line is: they could be a simple 0 + 0 and the system would show the same oddity.

Of course if I set the passed value to 0, the reported line is the line where Engine::Debug::GetPreviousCallstackLine() is called - as expected. If I set it to 2 it currently reports the line of execution one step even further in the future - though I thought the past would be a lot more defined.

-- EDIT --
GetPreviousCallstackLine(const uint &in a = 1) was GetPreviousCallstackLine(const uint &in a = 2)
The actual value used in my tests was 1, the 2 was spurious, coming from me exploring the system. Edited by Ricky C.

Share this post

Link to post
Share on other sites
I fixed a bug in GetLineNumber() in the WIP yesterday. When calling the method for numbers above 0 it was returning the line for the position where the function would return, and not the line where the function was called from. This meant that unless the return value was further used in the same expression the line number would be off by one.

I'm not sure when this bug was introduced, but it is highly likely that it is what you're facing in version 2.23.1.

You can probably patch your current version of AngelScript with the same fix.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!