Enum type safety in NPNGetValue

David Sehr sehr at google.com
Thu Jun 3 13:19:29 PDT 2010


As NPN_GetValue/NPP_GetValue can sometimes write pointer values, I would
argue that something like void** or intptr_t* as the argument type would be
better.  Some platforms (e.g., 64-bit Windows) have sizeof(void*) >
sizeof(long).

David

On Thu, Jun 3, 2010 at 12:18 PM, Stuart Morgan <stuartmorgan at chromium.org>wrote:

> Most of NPAPI is very clear about the size of types, but NPNGetValue's
> void* argument, combined with the various enums in NPAPI, seem to
> create the possibility for nasty bugs. When the variable passed to
> NPNGetValue is something like NPNVToolkit or NPNVpluginDrawingModel,
> the void* argument is a pointer to an enum value. My understanding is
> that in C++, enum size is unspecified, which means that the plugin and
> the browser could disagree about how much memory is pointed to,
> resulting in either memory stomping or unexpected values.
>
> Perhaps any time there is a variable like this, the specification
> should specify explicitly that the pointer is to a specific memory
> size (int32_t probably), so that the boundary point has a well-defined
> size, and both sides can then cast that int to and from the enum as
> necessary.
>
> Thoughts?
> _______________________________________________
> plugin-futures mailing list
> plugin-futures at mozilla.org
> https://mail.mozilla.org/listinfo/plugin-futures
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/plugin-futures/attachments/20100603/7beac02a/attachment.html>


More information about the plugin-futures mailing list