View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000202LDMudEfunspublic2004-11-26 22:432009-10-02 09: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.
External Data (URL)

Relationships

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

Activities

2004-11-27 01:23

 

p-990423-0.gz (945 bytes)

Issue History

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