size_t signature change breaks 32-bit only code

[janjongboom]

I have lots of 32-bits only code which has a number of assumptions around the size of size_t being an int, not a long. This is all code written for 32-bit microcontrollers. In the past this never caused any issues (all the targets that this code target are 32-bit targets anyway) with Emscripten, but since #5916 landed this yields a bunch of broken changes.

Last I checked Emscripten was still a 32 bits platform. Could we get some option to switch the size_t definition back to 4 bytes?

[juj]

size_t definition is still 32 bits, since long on Emscripten is 32 bits as well.

[janjongboom]

@juj That's interesting then... Because I see compilation errors about size_t being redefined as unsigned int vs. unsigned long. If they're the same underlying type I wouldn't expect this...

[juj]

Even though int and long have the same size, that does not mean that they are the same type. If I understand correctly, after the change, there should not exist any code in Emscripten that would define size_t to unsigned int.

[kripken]

Yeah, it's an oddity of C and C++ that int and long can be the same size - really they are both just int32_t - but the type system considers them differently. The size_t change from int to long can lead to results like this.

cc @sunfishcode - here's another report of a regression caused by your PRs.

[janjongboom]

@juj @kripken Thanks for the quick reply. It's kind of unfortunate to see this assumption in many libraries for Cortex-M processors but it's also not easy to patch. I've updated the libraries we ship with our Emscripten-based simulator, but expect many more libraries to break (without us knowing this), so some way to redefine size_t, even when it's a macro would be appreciated.

[kripken]

I don't think it would be practical for us to allow redefining size_t - it would mean potential bugs with linking code built in different ways, and also we'd need to handle multiple cases in our system linking code, etc.

Instead, I think we should consider reverting the size_t change. There has been more fallout than we expected, maybe we got that decision wrong.

[kripken]

@janjongboom I think it would be useful to get more details on what exactly is the situation you are hitting. I initially thought this was similar to other cases, but re-reading here I'm not sure.

Any chance you can create a standalone testcase showing the issue? Or to go into more detail about the specifics?

[janjongboom]

@kripken

1. Code that includes typedef size_t int (which should be wrong anyway, but OK).
2. printf("recv %d [%.*s]\n", rcount, strstr(buffer, "\r\n")-buffer, buffer); now needs to have strstr()-buffer casted to int.

[sunfishcode]

@janjongboom

For 1., Yeah, #include <stddef.h> is the simplest way to get size_t.

For 2., .* is indeed defined to take an int, so yes, that code would be incorrect on any platform where ptrdiff_t isn't int. That includes all 64-bit platforms these days, but also 32-bit MacOS, 32-bit OpenBSD, 32-bit NetBSD on ARM, among others.

If you're porting the code to wasm, perhaps it it's useful beyond microcontrollers, so would it make sense to make a change to improve its portability?

[janjongboom]

@sunfishcode It's not my code, it just runs in my Emscripten-based simulator.

[sunfishcode]

There are goals which conflict here. One is to maximize portability of existing code. Another is to build the best platform we can for the long term. It's admittedly not a clear choice. The value of eliminating minor frictions when migrating between wasm32 and wasm64 is not huge (and I recognize that wasm64 isn't a thing yet), but it could matter for a long time, probably as long as people are compiling C/C++ to wasm.

The inconvenience of needing to update the code in question, for whoever maintains it, is significant. However in the cases we've seen so far, it can be fixed by a one-time effort. So my preference here is to see if we can get by with fixing the cases that hit this. I'd be happy to help, if there's anything I can do, including sending a patch or PR, if the code is open-source.

[janjongboom]

Sure, it's a thin line but I believe Emscripten should offer a stable API and where possible not break userland applications in a minor release.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.