Enum type safety in NPNGetValue

John Newlin jnewlin at google.com
Thu Jun 3 13:27:04 PDT 2010


I'd suggest declaring the enum like so:

enum Foo {
 Bar = 1,
 FooBar = 2,

 Foo_ForceInt32 = 0xffffffff
};

That works on every compiler that I've tried, to make the enum always
be a 32-bit value.

-john


On Thu, Jun 3, 2010 at 1:19 PM, David Sehr <sehr at google.com> wrote:
> 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
>
>
> _______________________________________________
> plugin-futures mailing list
> plugin-futures at mozilla.org
> https://mail.mozilla.org/listinfo/plugin-futures
>
>


More information about the plugin-futures mailing list