Re: Plugin Interface: xchat_list API

[Peter Zelezny <zed@linux.com>]

On 14 Mar 2002 04:49:45 -0800
Alexander Hvostov <root@aoi.dyndns.org> wrote:

> The generic method would be used like this:
> 
> --- BEGIN CODE SNIPPET ---
> XChat xchat; // defined elsewhere
> DCC[] list = (DCC[]) xchat.getList("dcc");
> --- END CODE SNIPPET ---
> 
> If the list 'dcc' does not exist, an exception is thrown. Otherwise, an
> array of the correct type (DCC[]) is returned. Or perhaps it would be
> Object[] with only DCC elements. I'll have to figure that out when I go
> to implement this.

Having two ways to access the lists is probably not the best, but we're
getting there :)


> But surely that can be exploited maliciously. What if the plugin author
> calls xchat_list_str on "cps"? (Hint: Segmentation fault. Or worse.)

Nope. xchat_list_str has a big fat case statement that searches
through all the fields it knows. It won't find "cps", and return NULL.
Besides, if a plugin wants to crash the system, you can't prevent it (at
least a C one). Of course you want to protect against Java ones doing that.


> Remember that, unlike C code, Java code is _not_ considered trusted, and
> so mustn't be allowed to do anything that could compromise the system's
> security.

That's where your interface/glue routines come in and return something
like a "" string instead of NULL. Or whatever will make the java plugin happy
(throw a unknownField exception?).


> > No point in calling it xchat.add_command in Java, xchat_hook_command
> > in C and xchat.add_cmd_handler in python etc.
> 
> How about 'hookCommand'?

Yeah sounds ok. I know java people like the "lowerUpper" style names :)


> > I think the indexing using 'i' is unimplementable though.
> 
> Because it's a singly linked list?

Well yeah sort of. It's not provided as an array in C, so you'd probably
need to make a COPY of the entire list before being able to index it
with 'i'. Making a copy means you need to know all the fields available
(yeah we're back here again).

> --- BEGIN CODE SNIPPET ---
> XChat xchat; // defined elsewhere
> 
> for (Iterator i = xchat.getList("dcc"); i.hasNext();)
>   System.out.println("File: " +
>                      ((XChatListElement) i.next()).getField("file"));
> --- END CODE SNIPPET ---
> 
> As before, this would throw an exception if the field doesn't exist.
> 
> In this configuration, we can have a DCC class (like the previous
> example), but we don't reference this class by name. That way it gets
> past the compiler.

That looks pretty good. But I think you'd still need a field/type
list. Unless... is having getFieldStr and getFieldInt such a bad thing?


> One last thing. In Java, it is possible to access a class, method, etc
> that doesn't exist at compile time but does exist at run time, using the
> Reflection API.
> 
> --- BEGIN CODE SNIPPET ---
> XChat xchat; // defined elsewhere
> 
> for (Iterator i = xchat.getList("dcc"); i.hasNext();) {
>   Object o = i.next();
> 
>   System.out.println("File: " +
>     o.getClass().getMethod("getFile", new Class[] {}).invoke(o, new
>       Object[] {});
> }
> --- END CODE SNIPPET ---
> 
> This way, you can get it past the compiler. It's harder than having a
> generic way of getting fields, like above, but it's still possible.
> 
> Regards,
> 
> Alex.

Now you're just scaring me.


-- 
Peter Zelezny. <zed@linux.com>
--
XChat-discuss: mailing list for XChat users
Archive:       http://mail.nl.linux.org/xchat-discuss/