View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000202LDMudEfunspublic2004-11-26 21:432009-10-02 07:55
ReporterlarsAssigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status newResolutionopen 
Summary0000202: New efuns: previous_program()
DescriptionShort: New efun: previous_program(), program_stack()
From: Daniel Sloan <sloand@alphalink.com.au>
From: Michael <virus@mpinet.net>
Date: Tue, 23 Mar 1999 15:29:14 +0000
Type: Feature
State: Unclassified

Maybe also an efun program_stack()?

Daniel writes:

A 'previous_program' efun, parallel to previous_object(). Real handy for
tracing certain things and working out where a call was *really* made from.
I've not implemented this in the current driver I use, only an old 3.1.2
driver =-)

Michael writes:

After looking through a DGD driver source code, there is something
similar to the previous_object() function, but called
previous_program(). I don't have that much knowledge of the DGD driver,
but from what I found, this previous_program() could be used as a good
base for making a better security system for alot of mudlibs.

Excerpt from kfun/std.c under the DGD src directory:

/*
 * NAME: kfun->previous_program()
 * DESCRIPTION: return the previous program in the function call chain
 */
int kf_previous_program(nargs)
int nargs;
{
    char *prog;
    register string *str;

    if (nargs == 0) {
        (--sp)->type = T_INT;
        sp->u.number = 0;
    } else if (sp->u.number < 0) {
        return 1;
    }

    prog = i_prev_program((int) sp->u.number);
    if (prog != (char *) NULL) {
        sp->type = T_STRING;
        str = str_new((char *) NULL, strlen(prog) + 1L);
        str->text[0] = '/';
        strcpy(str->text + 1, prog);
        str_ref(sp->u.string = str);
    } else {
        sp->u.number = 0;
    }
    return 0;
}

Think something like this would be viable for the LD project/driver?
I found the DGD driver from ftp.imaginary.com server if you wish to
follow up on it more.

-- Michael

Rodney writes:

> When you use extern_call() within a module which is inherited, it is
> difficult to tell when a function is being called externally or not.
>
> For example, if you had two modules A and B which contained:
>
> // File : /obj/modules/a
> // Module A
>
> query_extern() { return extern_call(); }
>
> // File : /obj/modules/b
> // Module B
>
> inherit "obj/modules/a";
>
> query_extern() { return ::query_extern(); }
>
>
> If you call query_extern(), in Module A, it will return 1 or 0 depending on
> whether you used call_other(), or some external function, as documented.
> If you call query_extern() using call_other(), in Module B, it will always
> return 0.
>
> One possible solution is to modify extern_call() so that its behaviour
> changes depending on the situation. If a function Y calls a function X,
> which calls extern_call(), it should either:
>
> (1) KEEPS ITS CURRENT BEHAVIOUR.
> if X != Y (i.e. X has not got the same name, or is from a
> different object to Y)
>
> (2) BEHAVE AS IF IT WAS CALLED FROM Y.
> if X == Y (i.e. X has the same name as Y and is from the same
> object).
>
> Another solution is to create a new function e.g.
>
> extern_func_call()
>
> which behaves in the manner just described.
>
> Or yet another solution is to provide a efun which returns a list of
> function names in the current call stack, and the objects they came from.
TagsNo tags attached.
Attached Files
p-990423-0.gz (945 bytes)
External Data (URL)

Relationships

related to 0000586 new Allow querying single stack frames using debug_info(DINFO_TRACE) 

Activities

Issue History

Date Modified Username Field Change
2004-11-26 21:43 lars New Issue
2004-11-27 00:23 lars File Added: p-990423-0.gz
2009-10-02 07:55 zesstra Relationship added related to 0000586