Last Comment Bug 685820 - Fix uint64/uint64_t breakage in PluginMessageUtils.h
: Fix uint64/uint64_t breakage in PluginMessageUtils.h
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: Trunk
: x86_64 OpenBSD
-- normal (vote)
: mozilla9
Assigned To: Landry Breuil (:gaston)
: Benjamin Smedberg [:bsmedberg]
Depends on: 634793
  Show dependency treegraph
Reported: 2011-09-09 04:08 PDT by Landry Breuil (:gaston)
Modified: 2012-05-19 01:34 PDT (History)
4 users (show)
emorley: in‑testsuite-
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

uses uint64 instead of uint64_t (892 bytes, patch)
2011-09-09 04:10 PDT, Landry Breuil (:gaston)
cjones.bugs: review+
Details | Diff | Splinter Review

Description User image Landry Breuil (:gaston) 2011-09-09 04:08:19 PDT
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 :

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 :
Comment 1 User image Landry Breuil (:gaston) 2011-09-09 04:10:16 PDT
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.
Comment 2 User image Landry Breuil (:gaston) 2011-09-09 04:13:08 PDT
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 3 User image Josh Aas 2011-09-09 10:52:01 PDT
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.
Comment 4 User image Ed Morley [:emorley] 2011-09-20 03:26:02 PDT
This is now in my queue of things that are being sent to try then onto inbound :-)
Comment 6 User image Marco Bonardo [::mak] 2011-09-21 02:53:03 PDT

Note You need to log in before you can comment on or make changes to this bug.