Compiler suggestion

[Mike Stefanik]

If you have a function declared that doesn't return a value, and you attempt to assign a variable to it, then the compiler correctly returns the error "invalid assignment". For example:

Code Select Expand


declare foo(int bar);
int n;

n = foo(2); // error, function doesn't return a value


However, it doesn't check if you're using the function in an expression:

Code Select Expand


declare foo(int bar);

if (foo(2) = 4) // error, but it compiles anyway
     do_something();


The end result is that it generates code that will (most likely) result in a protection fault. I think the compiler should report an error just as if you performing an assignment. I found this because I was debugging a test program that kept crashing; it turned out that I had forgotten the ", int" at the end of the function declaration.

Edit: Forgot to mention that the compiler also won't complain if the function declaration doesn't have a return value, but the implementation of that function does. For example:

Code Select Expand


class test
{
     declare foo(int bar);
}

test::foo(int bar), int
{
    return bar + 1;
}


I think it should also catch that inconsistency, reporting an error when it encounters the implementation that doesn't match the function declaration.

And while I'm at it, another suggestion would be to warn folks when they're using a string literal that doesn't have a valid escape. For example, I think it should issue a warning if the string "c:\temp\system.txt" is used because what the developer almost certainly wants is "c:\\temp\\system.txt" (the "\s" isn't a valid escape sequence).

It would also be nice to implement the C# @ operator which tells the compiler that the string is to be interpreted literally. In other words:

Code Select Expand


string foo;
foo = @"c:\temp\system.txt";


[Parker]

As for the declaration matching the definition, the compiler only really cares about the declare if you have one. For example, try this

Code Select Expand

declare MySub(int x),int;

sub MySub(),string
{
    return x;
}
it compiles fine and runs fine. Kind of odd, and definitely something that should be mentioned in the users guide.

An @"" string won't be hard, I can do that if Paul accepts it into the language.

As for the expression, I agree it should be checked. But no, there won't be any problem because the eax register exists whether you returned a value or not. Most likely it will have the last function call or something used by the compiler when emitting that expression.

[Mike Stefanik]

The function call that didn't have a return value in the declaration, but was being used in an expression, was definitely the culprit in the program crashing (access violation). I fixed the function declaration and it worked without a hitch.