On Sat, Sep 10, 2022 at 10:36 AM Floh <[email protected]> wrote:
> PS: also I just noticed that allocateUTF8OnStack is on your list of
> 'legacy functions', but calling this works just fine in my code. I guess
> those are pulled in from some library_*.js that's linked into my code?
>
> What's the lowest level set of stack helper functions that won't go away?
> Is withStackSave(), stackAlloc() and stringToUTF8() guaranteed at least?
>
The hope is that we can move away from including any code that is not
explicitly needed, and not include any of these functions by default.
How/where are you calling these functions? I assume it is something like
EM_JS or EM_ASM, since if you were doing it in a JS library then you could
add explicitly dependencies.
If you are indeed using EM_ASM/EM_JS and expecting to be able to call
library functions then it sounds like we need to add some kind of
dependency mechanism for EM_ASM/EM_JS user code.
Alternatively we could use some kind of analysis of the EM_JS/EM_ASM
strings.. perhaps we could just do a dumb conservative string scanner, or
use a JS parser to find any used symbols.
> On Saturday, 10 September 2022 at 19:27:10 UTC+2 Floh wrote:
>
>> I just noticed that I had two remaining calls to ccall() where I used the
>> string argument marshalling feature (in all other cases I call functions on
>> the C side directly). I have those cases now replaced with (essentially)
>> "withStackSave(() => { ... allocateUTF8OnStack() ... }"
>>
>> Is this "kosher"? (I'm aware of the risk that these functions may go away
>> one day).
>>
>> I don't want to impose specific compiler flags (like LEGACY_RUNTIME) on
>> my library users, that's why I had to replace ccall() (unless there's a
>> another way to inject ccall into the code than through compiler options?).
>>
>> It would be nice to have a guaranteed set of these low level C interop
>> functions btw (like this withStackSave, allocateUTF8OnStack stuff).
>>
>> Cheers!
>> -Floh.
>>
>> On Tuesday, 6 September 2022 at 19:35:05 UTC+2 Shlomi Fish wrote:
>>
>>> On Tue, 6 Sep 2022 09:06:27 -0700
>>> "'Sam Clegg' via emscripten-discuss" <[email protected]>
>>> wrote:
>>>
>>> > Starting with 2.1.21, in order to make the default output size smaller
>>> some
>>> > runtime functions are transitioning to library functions. In debug
>>> builds,
>>> > if you try to use these functions, you should see an actionable
>>> warning.
>>> >
>>> > From the changelog:
>>> >
>>>
>>> Thanks for the warning, Sam!
>>>
>>> > - The `LEGACY_RUNTIME` setting is no longer enabled by default. If you
>>> use
>>> > any
>>> > of these legacy runtime functions (except in library code with
>>> explicit
>>> >
>>> > dependencies) then you would need to set `LEGACY_RUNTIME` on the
>>> command
>>> > line
>>> > or add the ones you need to `DEFAULT_LIBRARY_FUNCS_TO_INCLUDE`:
>>> >
>>> > - addFunction
>>> >
>>> > - removeFunction
>>> >
>>> > - allocate
>>> >
>>> > - AsciiToString
>>> >
>>> > - stringToAscii
>>> >
>>> > - UTF16ToString
>>> >
>>> > - stringToUTF16
>>> >
>>> > - lengthBytesUTF16
>>> >
>>> > - UTF32ToString
>>> >
>>> > - stringToUTF32
>>> >
>>> > - lengthBytesUTF32
>>> >
>>> > - allocateUTF8
>>> >
>>> > - allocateUTF8OnStack
>>> >
>>> > - writeStringToMemory
>>> >
>>> > - writeArrayToMemory
>>> >
>>> > - writeAsciiToMemory
>>> >
>>> > - intArrayFromString
>>> >
>>> > - intArrayToString
>>> >
>>> > - warnOnce
>>> >
>>> > - ccall
>>> >
>>> > - cwrap
>>> >
>>> > Although this is technically a breaking change for those who use these
>>> >
>>> > functions, there are assertions in debug builds that catch such usages
>>> > and
>>> > direct towards how to fix the issue.
>>> >
>>> > I hope this change is not too disruptive and overall a move in the
>>> right
>>> > direction.
>>> >
>>> > cheers,
>>> > sam
>>> >
>>>
>>>
>>>
>>> --
>>>
>>> Shlomi Fish https://www.shlomifish.org/
>>> Chuck Norris/etc. Facts - https://www.shlomifish.org/humour/bits/facts/
>>>
>>> If Botticelli were alive today, he’d be working for Vogue.
>>> — https://en.wikiquote.org/wiki/Peter_Ustinov
>>>
>>> Please reply to list if it's a mailing list post -
>>> https://shlom.in/reply .
>>>
>> --
> 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].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/39749284-d7df-4e03-aea7-83362d5ef36cn%40googlegroups.com
> <https://groups.google.com/d/msgid/emscripten-discuss/39749284-d7df-4e03-aea7-83362d5ef36cn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/emscripten-discuss/CAL_va29ve-8P-bjAEAj2Utk3%3DJoQw4E0fsWquc_NmVYnUXmnCA%40mail.gmail.com.
