Followup to bug #682759, trunk now fails to build on OpenBSD/amd64 with the following error message : ../../dist/include/mozilla/plugins/PluginMessageUtils.h: In staticmember function 'static bool IPC::ParamTraits<mozilla::plugins::NPRemoteWindow>::Read(const IPC::Message*,void**, mozilla::plugins::NPRemoteWindow*)': ../../dist/include/mozilla/plugins/PluginMessageUtils.h:389: error:invalid conversion from 'uint64_t*' to 'uint64*' ../../dist/include/mozilla/plugins/PluginMessageUtils.h:389: error:initializing argument 2 of 'bool Pickle::ReadUInt64(void**, uint64*) const' Introduced by that commit : http://hg.mozilla.org/mozilla-central/rev/1bba630bb3a0 This is not the first time it happens, usually it's the other way round (ie using an uint64 where an uint64_t should be used). Discussions about jstypes happened here : https://bugzilla.mozilla.org/show_bug.cgi?id=662852
Created attachment 559412 [details] [diff] [review] uses uint64 instead of uint64_t Attached patch fixes the issue, but i'm not sure at all this is the correct fix.
By 'not sure this is the correct fix' i mean the other types used in that header are legit _t types, so maybe readuint64 proto should be amended/fixed to take a _t type ? or all others uint64_t should be replaced by uint64 (coming from nspr iirc...)
Comment on attachment 559412 [details] [diff] [review] uses uint64 instead of uint64_t So long as the end result is a 64-bit unsigned integer on all platforms I don't have a type preference. Lets get Chris Jones to make a decision, he's probably run into this before.
This is now in my queue of things that are being sent to try then onto inbound :-)