One of the main benefits of making size_t be unsigned long is that it eliminates some C++ name mangling differences between wasm32 and wasm64. If we change either int32_t or int64_t, it would introduce new name mangling differences.
If we find more issues, we should reevaluate the options, but so far we only know of one case, and it's already fixed upstream, and there's a workaround posted in this thread as well. Dan On Wed, Aug 8, 2018, 10:58 AM 'Sam Clegg' via emscripten-discuss < [email protected]> wrote: > I'm running into this same issue internally too. > > Its seems kind of unfortunate that `intptr_t*` is neither compatible > with `int64_t*` nor `int32_t*`. The code in question (which has thus > far been fairly portable) seems to make this assumption. Could/Should > we change `int32_t*` so that it also `long` and therefore > interchangeable with `size_t`? > On Fri, Jul 27, 2018 at 11:53 AM Dan Gohman <[email protected]> wrote: > > > > Hello, > > > > The change you described to ProtobufOnceType here seems like it should > work. Going forward, this code in newer versions of protobuf has changed > and looks like it should avoid this problem. This patch: > > > > > https://github.com/google/protobuf/commit/0400cca3236de1ca303af38bf81eab332d042b7c#diff-c1a3f69dda9164a2db00255845f17a34R97 > > > > changed the type of ProtobufOnceType. > > > > Dan > > > > > > On Fri, Jul 27, 2018 at 2:30 AM, Александр Гурьянов <[email protected]> > wrote: > >> > >> I believe that protobuf have this defenition of types (for 32bit build): > >> > >> typedef int32 Atomic32; > >> typedef int64 Atomic64; > >> > >> typedef intptr_t AtomicWord; > >> typedef internal::AtomicWord ProtobufOnceType; > >> > >> AtomicWord should be same as Atomic32, so if you say that intptr_t still > >> remains 32bit integer then easiest fix will be: > >> > >> Change in atomicops.h defenition of AtomicWord to: > >> > >> #ifdef EMSCRIPTEN > >> typedef Atomic32 AtomicWord; > >> #else > >> typedef intptr_t AtomicWord; > >> #endif > >> > >> This will not be safe if "things" are changed. If I force protobuf to > 64bit, > >> error still there because Atomic64 will be long long, but intptr_t > >> long. Probably it's > >> better to compile with -DGOOGLE_PROTOBUF_NO_THREAD_SAFETY, but I never > >> have success > >> to building it with that flag. > >> > >> Anyway now it works. > >> пт, 27 июл. 2018 г. в 10:58, Александр Гурьянов <[email protected]>: > >> > > >> > I think because with this change now I can't compile protobuf library, > >> > with this error: > >> > > >> > protobuf-3.0.2/src/google/protobuf/stubs/once.h:135:30: error: cannot > >> > initialize a parameter of type 'const volatile > >> > google::protobuf::internal::Atomic32 *' (aka 'const volatile int *') > >> > with an lvalue of type 'google::protobuf::ProtobufOnceType *' (aka > >> > 'long *') > >> > if (internal::Acquire_Load(once) != ONCE_STATE_DONE) { > >> > > >> > I just found this error, I will keep your updated if I can solve it. > >> > > >> > вт, 24 июл. 2018 г. в 19:33, Alon Zakai <[email protected]>: > >> > > > >> > > On incoming and 1.38.10 we landed > >> > > > >> > > https://github.com/kripken/emscripten/pull/5916 > >> > > > >> > > which changes the type of size_t etc. from int to long. This helps > synchronize the asm.js and wasm ABIs, and will be convenient for future > versions of wasm (wasm64). > >> > > > >> > > This should not be noticeable in most cases, as it remains a 32-bit > integer. However, if you depend on the name mangling of a C++ function that > uses `size_t` (like in `EXPORTED_FUNCTIONS`), then the name might change > slightly ('m' replaces 'j' for size_t). You also need to rebuild source > files to bitcode so your bitcode is in sync with the system libraries after > they are rebuilt with this change (rebuilding for any new version is > recommended anyhow - we rebuild system libraries at that time). Finally, > printf of a size_t using %u etc. may now show a warning (but is harmless), > which you can avoid with adding a z, %zu etc. > >> > > > >> > > - Alon > >> > > > >> > > -- > >> > > You received this message because you are subscribed to the Google > Groups "emscripten-discuss" group. > >> > > To unsubscribe from this group and stop receiving emails from it, > send an email to [email protected]. > >> > > For more options, visit https://groups.google.com/d/optout. > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups "emscripten-discuss" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > >> For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > You received this message because you are subscribed to the Google > Groups "emscripten-discuss" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
