ID:2018627
 
BYOND Version:509
Operating System:Windows 10 Home 64-bit
Web Browser:Chrome 47.0.2526.106
Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:

Any usage of call() within your source will trigger the external DLL security warning when running your world, regardless of if it's being used on a DLL or not.

Numbered Steps to Reproduce Problem:

1) Create project.
2) Add any code that utilizes call().
3) Run game.
4) See external DLL security warning.

Code Snippet (if applicable) to Reproduce Problem:
mob/proc/Test()
src << "Hello [src.name]!"

Login()
..()
call(src,"Test")()


Expected Results:

Compiler to only set security flag when it detects a dll/so file as the first argument to call(), not when any usage is made.

Actual Results:

Security warning about external libraries.

Does the problem occur:
Every time? Or how often? Every time.
In other games? Any project with call() used.
In other user accounts? Yep.
On other computers? Yep.

When does the problem NOT occur? When call() isn't used anywhere.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)

Seems to happen all the way back to when the warning was added.

Workarounds:

Nada.
Something tells me this isn't a trivial fix... The compiler may not be aware if the call is intended for a DLL or not.
In response to NullQuery
NullQuery wrote:
Something tells me this isn't a trivial fix... The compiler may not be aware if the call is intended for a DLL or not.

Yeah, this is a tough problem. It may be solvable, but I'll have to look into it and run a lot of tests.

There are basically ten different call() instructions--five families, each with a regular and an arglist version. (Two of the families are for .() and ..() though: CALL_ME_INST and CALL_PREV_INST. The other one not mentioned is CALL_FIXED_INST, which has a hard-coded proc reference; I'm pretty sure that's only a normal proc call and not actually ever used by call() itself.)

The logic that controls whether it gets compiled as a regular call or a DLL call is here:

new_inst = (verb->children->nod[0]->val.type==linkty) ? CALL_SRC_INST : CALL_EXT_INST;

I think it makes some sense when the first argument (nod[0]) is a reference to src or usr, that we can expect it's not a string and therefore not use the CALL_EXT_INST instruction. It might even make more sense to simply disallow the library to be specified dynamically--honestly I don't think that would ever happen--and always compile as CALL_SRC_INST if the first argument is not a constant string.
This isn't happening for me. Used your exact code in both DS and DD in both safe and ultrasafe mode and didn't get any warnings. Running 509.1308 with Windows 10 64 bit and Chrome 47.0.2526.106. Not sure what the difference is...
Although it isn't relevant to this, you should upgrade to 509.1319.
I'm seeing the same results as Flick when testing this code.
In response to Lummox JR
Lummox JR wrote:
Although it isn't relevant to this, you should upgrade to 509.1319.

I'm actually on 1318, but yeah I'll upgrade. ;)
If you've accepted the prompt once before it won't appear again, you'd have to remove the entry from trusted.txt to cause it to trigger again.