-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow string operators to be disabled #80
base: develop
Are you sure you want to change the base?
Conversation
Fixed the example. |
The idea is interesting but going out and checking the application environment for every concatenation call is a bit too slow. It also depends on the luerl application being loaded which is actually not needed now. |
As I recall it, the reason I didn't use erlc macros was that I could not figure out how to configure them in Mix. If this is too slow, I could read the environment variable at compile time.
If the application is not loaded, get_env will return nil, so people will only have to configure the application if they want to use this specific feature. I will likely get back to this PR in a month, when I might add the option to allow concatenations when the combined byte size does not exceed 64. |
I modified the rebar script to also take configuration from the app env. I'd say this is good to go now. |
Renamed |
* Store identifiers as strings rather than atoms at no penalty * Limit identifier size to 64 characters if SANDBOX_STRINGS is set
Changed identifier storage from atoms to strings because they are only used as strings and dynamic atom creation is scary. |
This seriously impedes further progress where logical gates (such as inclusive/exclusive gateway) can be used. Solution: execute scripts using Lua (luerl) as the first available language Luerl is not perfect (but one can contribute to its development, I guess?) and have some issues (see rvirding/luerl#80 for a concerning example) but that's the best one I can find that's *known* and works.
4fdcb90
to
c439c82
Compare
76b3c9b
to
2124269
Compare
@bopjesvla do you still have an interest in solving this problem? Since the PR is stale now, I will plan to close in a week or two unless I hear otherwise |
In Erlang's current state, it's impossible to impose memory limits on a process that allows string manipulation.
max_heap_size
does not help here, since large binaries are stored off-heap.Most ways to manipulate or dynamically generate strings (string.*, tostring, and perhaps pcall) can already be disabled (#77). This PR introduces a way to disable string concatenation and other future string operators. For reference: